Re: SCSI changes - PR58452 for review

[Nat Sloss <nathanialsloss%yahoo.com.au@localhost>]

On Sat, 3 Aug 2024 16:03:29 Rin Okuyama wrote:
> Aren't the failures due to bugs and/or hardware limitations for
> BlueSCSI? If so, should these be handled by drivers?
> 

These changes are only necessary when using BlueSCSI/RASCSI/PiSCSI with 
wireless.  It only changes the way sbc handles aborts only noticable when 
using dse(4) as it needs input to be polled io.

> I've used SCSI2SDv6 and ZuluSCSI for years. Both works just
> fine for esp(4) on Quadra/Quadra AV, as well as ncr53c9x-based
> card for amiga:
> 
> https://dmesgd.nycbug.org/index.cgi?do=view&id=6714
> 

I noticed in the dmesg that dse(4) was not in use.  This problem only occurs 
when using the device with another device on the scsibus performing frequent 
polled io such as dse(4) does.


You may say that these problems should be handled by a firmware update to the 
BlueSCSI device.  However I'm only working with these devices in their current 
state and aborting transfers should be handled better by the kernel as well as 
retrying on meduim errors to make the 5380sbc and scsi within the kernel more 
robust.


If situations like this were to happen back in the day...you couldn't 
necessarily rely upon a manufacturer to provide a firmware update for their 
hard disk (let alone if it was possible to flash the firmare).


Nat

> Thanks,
> rin
> 
> On 2024/08/03 9:37, Jason Thorpe wrote:
> >> On Aug 2, 2024, at 4:59 PM, Nathanial Sloss
> >> <nathanialsloss%yahoo.com.au@localhost> wrote:
> >> 
> >> I'll wait another two weeks before commiting anything should issues
> >> arise.
> > 
> > Hey Nat -
> > 
> > These changes look good to me.  Can you please file a follow-up bug for
> > this comment?
> > 
> >   	/* XXX - Need to cancel disconnected requests. */
> > 
> > Thx!
> > 
> > -- thorpej