Re: kern/58452 (NCR5380 SCSI fixes for aborting transfers. BlueSCSI(v2))

[" Nathanial Sloss via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58452; it has been noted by GNATS.

From: Nathanial Sloss <nathanialsloss%yahoo.com.au@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/58452 (NCR5380 SCSI fixes for aborting transfers. BlueSCSI(v2))
Date: Sun, 15 Sep 2024 09:32:46 +1000

 On Sun, 11 Aug 2024 06:05:01 Michael van Elst wrote:
 > The following reply was made to PR kern/58452; it has been noted by GNATS.
 > 
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/58452 (NCR5380 SCSI fixes for aborting transfers.
 > BlueSCSI(v2)) Date: Sat, 10 Aug 2024 20:03:13 -0000 (UTC)
 > 
 >  nathanialsloss%yahoo.com.au@localhost (Nathanial Sloss) writes:
 >  > [   1.0000000] Apple Macintosh PowerBook 160  (68030)
 >  > 
 >  > [ 1540.8555152] panic: ncr5380_scsipi_request: polled request, abort
 >  > failed [ 1540.8555152] cpu0: Begin traceback...
 >  > [ 1540.8555152] ?(?)
 >  > [ 1540.8555152] db_panic(0,62f800,3d27d74,13000c,1b7c04) at 0
 >  > [ 1540.8555152] vpanic(1b7c04,3d27d80,3d27da8,3991e,1b7c04) + 18c
 >  > [ 1540.8555152] panic(1b7c04,1b7cb8,12fe10,1,23b16) + c
 >  > [ 1540.8555152] ncr5380_scsipi_request(62f83c,0,6b5e3c,62f834) + c6
 >  > [ 1540.8555152] scsipi_run_queue(?)
 > 
 >  That's a combination of dse(4) doing only polled requests (why?) and the
 >  ncr5380 driver (sys/dev/ic/ncr5380sbc.c) handling polled requests very
 > badly.
 > 
 
 I've since changed dse(4) it only needs reads to be polled.   Which is a quirk 
 of the emulated hw and ncr5380sbc.
 
 The patch just made it possible to handle aborts/and medium erros better on 
 5380sbc, which is only noticable when using sbc with a device such as dse(4) 
 sending frequent polled requests.
 
 >  It's also confusing that atari and mac68k have their own (similar) ncr5380
 >  drivers, but which aren't used. At a first glance, these drivers ignore
 >  a request for polled I/O, but probably run each command to completion
 > anyway.
 
 
 I highly doubt that dse(4) at least the emulated ones with BlueSCSI v2/ RASCSI 
 / PiSCSI will work, they most likely will have garbled input from dse(4) due 
 to issues with it's emulation.
 
 Nat
 
 PS: You may as well say that the issue is with the emulation of the DaynaLINK 
 SCSI device, but I'm only working with the current state of these devices 
 which could be handled better by the kernel and are more prevalent as failing 
 spinning disks are replaced.