On Mon, 2 Jan 2012, Perry Wagle wrote: > The instructions in usbmon.txt in last hours's current version of the kernel > refers to /proc/bus/usb/usbdevices, which doesn't exist in my current > fedora 16 kernel. But I think I figured out the bus number from the messages > log file. I have to fix that... It should say to look at the output from lsusb. > [What's the best way to send info like this? I use a macosx box for email, > but previously got chewed out for causing formatting problems on someone's > client. So, I'm doing my best to not do anything fancy.] Sending the data inline with your email message, as you did, is fine. > Here's two disks being plugged in, one disk working, and one disk going > into an infinite error loop: Okay, I see the immediate cause of the problem. > f114ab00 1784649616 S Bo:2:006:2 -115 31 = 55534243 01000000 24000000 80000612 00000024 00000000 00000000 000000 > f114ab00 1784649750 C Bo:2:006:2 0 31 > > f1148680 1784649866 S Bi:2:006:1 -115 36 < > f1148680 1786788960 C Bi:2:006:1 0 36 = 00000612 45000000 57444320 57443530 30304141 4b582d30 30314341 30202020 > f114ab00 1786789038 S Bi:2:006:1 -115 13 < > f114ab00 1786789198 C Bi:2:006:1 0 13 = 55534253 01000000 00000000 00 > f114ab00 1786789391 S Bo:2:006:2 -115 31 = 55534243 02000000 24000000 80010612 20000024 00000000 00000000 000000 > f114ab00 1786789430 C Bo:2:006:2 0 31 > > f26acb00 1786789532 S Bi:2:006:1 -115 36 < > f26acb00 1788808759 C Bi:2:006:1 0 36 = 00000612 45000000 57444320 57443530 30304141 4b582d30 30314341 30202020 > f114ab00 1788808792 S Bi:2:006:1 -115 13 < > f114ab00 1788808856 C Bi:2:006:1 0 13 = 55534253 02000000 00000000 00 These lines show the computer asking the two drives to identify themselves. They both claim to support ANSI SCSI revision level 6. However the usb-storage driver automatically reduces the level down to 2, and that messes things up. > f114ab00 1792858413 S Bo:2:006:2 -115 31 = 55534243 14000000 00100000 80010a28 20000000 00000008 00000000 000000 > f114ab00 1792858460 C Bo:2:006:2 0 31 > > effbe580 1792858473 S Bi:2:006:1 -115 4096 < > effbe580 1792858587 C Bi:2:006:1 -32 0 > f114ab00 1792858607 S Co:2:006:0 s 02 01 0000 0081 0000 0 > f114ab00 1792858713 C Co:2:006:0 0 0 > f114ab00 1792858727 S Bi:2:006:1 -115 13 < > f114ab00 1792858838 C Bi:2:006:1 0 13 = 55534253 14000000 00100000 01 Here's where things start to go badly wrong. This is the first READ command, and it is sent to the second drive (which is Logical Unit Number 1). The LUN value is encoded in the second byte of the command string, and I'm pretty sure that's what is confusing the drive. The corresponding command gets sent to the other drive (LUN 0) a little later, and it works okay -- the drives expect that byte to be 0. The two commands are the same except for the LUN byte, so it seems that's where the problem lies. And that makes sense. The LUN value is supposed to get stuck into the command string only for devices whose ANSI SCSI revision level is 2 or lower. Your drives don't like it, but currently there's no way to prevent this from happening. You can test this by applying the patch below. If it fixes the problem, we'll know the diagnosis is correct. Alan Stern drivers/usb/storage/scsiglue.c | 10 ---------- 1 file changed, 10 deletions(-) Index: usb-3.2/drivers/usb/storage/scsiglue.c =================================================================== --- usb-3.2.orig/drivers/usb/storage/scsiglue.c +++ usb-3.2/drivers/usb/storage/scsiglue.c @@ -217,16 +217,6 @@ static int slave_configure(struct scsi_d if (sdev->scsi_level > SCSI_SPC_2) us->fflags |= US_FL_SANE_SENSE; - /* Some devices report a SCSI revision level above 2 but are - * unable to handle the REPORT LUNS command (for which - * support is mandatory at level 3). Since we already have - * a Get-Max-LUN request, we won't lose much by setting the - * revision level down to 2. The only devices that would be - * affected are those with sparse LUNs. */ - if (sdev->scsi_level > SCSI_2) - sdev->sdev_target->scsi_level = - sdev->scsi_level = SCSI_2; - /* USB-IDE bridges tend to report SK = 0x04 (Non-recoverable * Hardware Error) when any low-level error occurs, * recoverable or not. Setting this flag tells the SCSI -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
