The following reply was made to PR port-mac68k/9679; it has been noted by GNATS.

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: Chuck Silvers <chuq@chuq.com>
Cc: Dave Huang <khym@azeotrope.org>, gnats-bugs@netbsd.org,
	hauke@Espresso.Rhein-Neckar.DE
Subject: Re: port-mac68k/9679 -- Using scsi/libscsi lets mac68k sbc driver
 dump core
Date: Sun, 15 Jan 2006 17:39:09 +0100

 At 12:02 Uhr -0800 14.1.2006, Chuck Silvers wrote:
 >On Wed, Jan 11, 2006 at 06:24:43PM -0600, Dave Huang wrote:
 >> I wonder if the sbc driver has problems if it's asked to read more
 >> data than is actually available. The scsi utility is attempting to
 >> read 255 bytes, even though chances are that the mode page isn't that
 >> long.
 >
 >well, it's part of the problem.  the sbc_pdma_in() is expecting to read
 >255 bytes, so is does the PDMA thing instead of PIO.  since datalen is
 >more than 128, it tries to do the first 128 bytes using 4-byte reads.
 >however, there are only 35 bytes of data, so when it tries to read the
 >ninth 4-byte value it gets a bus error since there are only 3 bytes left.
 >
 >so unless there's some way to know ahead of time how many bytes will
 >actually be read, it's not safe to use the 4-byte reads.  all of the
 >other sbc PDMA data movers use the "nofault" hook to catch bus errors,
 >and sbc_pdma_in() should too.  the attached patch will at least prevent
 >the panic, though it will miss transferring the last bytes if the number
 >of bytes transferred is not a multiple of 4.
 
 mirth# ./scsi -f /dev/rsd0c -m8 -P3 -v
 sbc_pdma_in: caught bus error
 IC:  0
 ABPF:  0
 CAP:  0
 DISC:  0
 SIZE:  0
 WCE:  0
 MF:  0
 RCD:  1
 Demand Retention Priority:  0
 Write Retention Priority:  0
 Disable Pre-fetch Transfer Length:  0
 Minimum Pre-fetch:  0
 Maximum Pre-fetch:  32
 Maximum Pre-fetch Ceiling:  63
 mirth#
 
 -- nice.  :)
 
 >we could try falling back to the byte-by-byte loop after a bus error on
 >the unrolled loop, does that seem likely to work?
 
 Meaning that after a bus error from the longword accesses, we pick one byte
 at a time until the next bus error tells us there is nothing more? Sounds
 good, although I wouldn't know how to write the code.
 
 From looking at mac68k/dev/mac68k5380.c, am I wrong in assuming that the
 ncrscsi driver would suffer from the same problem? (Test kernel is still a
 few hours from completion.)
 
 	hauke
 
 
 --
 "It's never straight up and down"     (DEVO)