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 > >> <[email protected]> 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
