[sent to kernel list since scsi doesn't appear to have a maintainer,
and CC'd to lnz in case it's a Buslogic issue]
I have the following SCSI devices all connected via a BT-958:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: MICROP Model: 4743 Rev: S150
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: QUANTUM Model: FIREBALL ST2.1S Rev: 0F0M
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: IBM Model: DDRS-34560D Rev: DC1B
Type: Direct-Access ANSI SCSI revision: 02
Under kernel 2.1.131 (and 2.0.x):
Queue depths: 10,7,28:
everything works fine
Queue depths: 10,28,28:
The second drive gets resets every few seconds, until TQ is disabled
then things are smooth
Under kernel 2.2.0-pre7-ac7:
Queue depths: 10,7,28:
The first drive gets into a continuous loop of SCSI resets, even after
TQ is disabled, and you get 'can't read inode' errors on the root partition.
hardware reset requred.
Queue depths: Disabled,28,28:
Everything works fine. Performance of the second drive is noticably better.
I know the second drive is a POS, though the first drive seems to be worse.
However, Linux does need to have a better mode of failure than continuous
bus resets.
The 'obvious' solution would be to blacklist the Micropolis drive,
as that seems to make the bus extremely stable, as well as make the
Quantum Fireball ST behave.
However, the change below doesn't appear to do anything.
BusLogic=TQ:N does fix the problem however.
The blacklisting is apparently being ignored due to a change I amde in the
driver when it started checking INQUIRY information directly. I will work on a
patch tonight and send it to you for testing. I've no idea as yet what happens
with 2.2.0pre7-ac7. The driver hasn't changed in quite a while, so most likely
something in the SCSI subsystem has been changed in an incompatible way.
Leonard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/