On Wed, Nov 09, 2005 at 08:04:30PM +0100, Manuel Bouyer wrote:
> OK, I think I tracked the problem down, but I can't test it as I have no
> drives that show this behavior. Please try the attached patch against 2.1

I don't have a lot of time, but I managed to download the kernel
sources, appy your patch, make a full backup and boot with the patched
kernel.  Unfortunately, the results weren't good.  Here is an example
of some messages I saw a number of times when booting up:

Nov 10 23:14:04 bix /netbsd: esiop0: scsi bus reset
Nov 10 23:14:04 bix /netbsd: sd0(esiop0:0:5:0): command with tag id 0 reset
Nov 10 23:14:04 bix /netbsd: sd0: async, 8-bit transfers, tagged queueing
Nov 10 23:14:04 bix /netbsd: sd1(esiop0:0:6:0): command with tag id 0 reset
Nov 10 23:14:04 bix /netbsd: sd1: async, 8-bit transfers, tagged queueing
Nov 10 23:14:04 bix /netbsd: sd0: sync (50.00ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
Nov 10 23:14:04 bix /netbsd: sd1: sync (50.00ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
Nov 10 23:14:04 bix /netbsd: esiop0: DMA IRQ: Illegal instruction DMA fifo empty, DSP=0x560 DSA=0x146c4c4: T/L/Q=5/0/0 last msg_in=0x4 status=0xff
Nov 10 23:14:04 bix /netbsd: esiop0: scsi bus reset
Nov 10 23:14:04 bix /netbsd: sd0(esiop0:0:5:0): command with tag id 0 reset
Nov 10 23:14:04 bix /netbsd: sd0: async, 8-bit transfers, tagged queueing
Nov 10 23:14:04 bix /netbsd: sd1(esiop0:0:6:0): command with tag id 0 reset
Nov 10 23:14:05 bix /netbsd: sd1: async, 8-bit transfers, tagged queueing
Nov 10 23:14:05 bix /netbsd: sd0: sync (50.00ns offset 16), 16-bit (40.000MB/s) transfers, tagged queueing
Nov 10 23:14:05 bix /netbsd: sd0(esiop0:0:5:0):  Check Condition on CDB: 0x23 00 00 00 00 00 00 00 0c 00
Nov 10 23:14:05 bix /netbsd:     SENSE KEY:  Illegal Request
Nov 10 23:14:05 bix /netbsd:      ASC/ASCQ:  Invalid Command Operation Code
Nov 10 23:14:05 bix /netbsd:          SKSV:  Error in CDB, Offset 0
Nov 10 23:14:05 bix /netbsd: 

The system did finally come up into multi-user mode, but sd0 was not
mounted.  sd0 was the disk that caused the original problem with the
2.1 kernel and sd1 is the boot disk which has never caused trouble
with any kernel.

-- 
Roy Bixler <rcbixler@nyx.net>
"The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment."
-- Richard P. Feynman