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.
--- drivers/scsi/scsi.c.virgin Mon Jan 18 13:21:24 1999
+++ drivers/scsi/scsi.c Mon Jan 18 13:22:29 1999
@@ -227,6 +227,7 @@
{"MAXTOR","XT-8760S","B7B", BLIST_NOLUN}, /* guess what? */
{"MEDIAVIS","RENO CD-ROMX2A","2.03",BLIST_NOLUN},/*Responds to all lun */
{"MICROP", "4110", "*", BLIST_NOTQ}, /* Buggy Tagged Queuing */
+{"MICROP", "4743", "*", BLIST_NOTQ}, /* Buggy Tagged Queuing */
{"NEC","CD-ROM DRIVE:841","1.0", BLIST_NOLUN}, /* Locks-up when LUN>0 polled. */
{"PHILIPS", "PCA80SC", "V4-2", BLIST_NOLUN}, /* Responds to all lun */
{"RODIME","RO3000S","2.33", BLIST_NOLUN}, /* Locks up if polled for lun != 0 */
--Simon
P.S. Any new drives will all be IBM.
-- Simon Karpen karpes@rpi.edu slk@acm.rpi.edu #include <std_disclaimer.h> I don't speak for RPI in any way. "Those that give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." --Ben Franklin
- 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/