On Jan 3, 2012, at 11:32 AM, Alan Stern wrote: > 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. mounting usbfs also works, but yeah. >> [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. With the patch, I'm able to mount both disks. Thanks! Now what? > Alan Stern -- Perry Wagle > 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
