I just accidentally sent the following to Alan off-list, so will copy again: >>> Haha, yes indeed. Thanks, that really helped. Looks like the command was getting sent by 'blkid' which is run as soon as the drive is detected. If I 'chmod 000 /sbin/blkid' then it works just fine. But I guess this will likely break some other stuff on the system. I shall raise this as a bug with the Ubuntu folks, and try to figure out a workaround in the meantime. <<< Although, looking at your message it would appear more fundamental than that. I can run badblocks, and dd a bunch of zeroes onto the drive. I haven't tried anything more fancy yet (like creating a filesystem) but it looks like actually blkid is doing the "correct" thing, but is being told something erroneous. Is there anything I can perform by hand to ignore this setting in the meantime? Thanks, Simon ----- Original Message ----- > Alan / Simon -- > > If you look at the device descriptors, it reports itself as an > SFF-8020i device. This kicks-in code to force all commands to > 12-byte, as (I think) required by 8020i. Of course, for a large > device like this, you might need 16-byte commands. > > This probably needs a protocol override to force it back to > transparent SCSI mode. Either that, or someone needs to take a longer > look at the 8020 spec, 8020 devices, and see if there is a way to make > it work without an override... > > Matt > > On Mon, Oct 24, 2011 at 8:54 AM, Alan Stern > <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, 24 Oct 2011, Simon Detheridge wrote: > > > >> > > Any ideas as to what I can do to make this work? > >> > > >> > The best way to start is to get a usbmon trace. There are > >> > instructions in the kernel source file > >> > Documentation/usb/usbmon.txt. > >> > >> Thanks for your reply. > >> > >> I ran usbmon, and inserted the drive. I didn't run any further > >> commands after insertion, just watched to see what happened. > >> > >> Dmesg said this: > >> http://pastebin.com/3v2ihQic > >> > >> Meanwile, usbmon said: > >> http://pastebin.com/38ZxSg6d (I have no idea what any of that > >> means!) > > > > Fortunately, I do! :-) > > > > The trace shows that an invalid READ(16) command was sent to the > > drive. > > In fact, you can see it in the dmesg log: > > > > [ 2603.289546] sd 9:0:0:0: [sde] CDB: Read(16): 88 00 00 00 00 01 5d > > 50 a3 00 00 00 > > > > 88 is indeed READ(16), but the command is supposed to be 16 bytes > > long, not 12 -- that's what the "(16)" in the name means. The drive > > should have refused to carry out the command and returned an error > > code, but > > instead it tried to do the command and then hung. > > > > It's hard to tell where that command came from, but since it was one > > of the first commands sent, it was probably some program associated > > with udev or ConsoleKit or something like that. You may be able to > > find out > > which program it was by running ps or lsof during the delays while > > the system is trying to read the drive. > > > > Alan Stern > > > > -- 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 > > > > > > -- Matthew Dharm > Maintainer, USB Mass Storage driver for Linux -- 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
