Messages in this thread | | | Date | Mon, 18 Jan 1999 11:07:34 -0800 (PST) | From | "Leonard N. Zubkoff" <> | Subject | Re: Wierd SCSI behavior change 2.1.131->2.2.0-pre7-ac7 |
| |
Date: Mon, 18 Jan 1999 13:49:08 -0500 (EST) From: Simon Karpen <slk@acm.rpi.edu>
[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/
| |