On Tue, 22 Jun 2004, Alan Stern wrote:
Anyway, it looks like there's a problem with the hub that's plugged into your computer. Does your device attach to an external hub? Apparently that hub has died; that's the reason for all those repeated -84 or -71 errors at the end of the logs. Or maybe you've got a compound device, with its own built-in hub. (The USB log from when you first plug in the device has that information.)
The card readers are connected to an external hub, and the final errors from the logs were probably when I unplugged the hub in a futile attempt to see if it would recover.
I have tried the card readers directly attached to the root USB ports on the computer (no hub), and the same problem occurs.
It's a little suspicious that your drive fails so quickly -- on the very first command it receives.
It's not quite the first command (see below). But it works through 2, 3, 10 cycles to start, then poof it fails all of a sudden when inserting a card (the card reader does not show up on the USB bus until a card is inserted). Whether inserting/removing cards from the reader, or plugging/unplugging the card reader from the hub/host, the failure is the same.
That makes me wonder if there isn't some sort of hardware problem either with the disk drive itself or with the USB-IDE converter. Or if you're using an external hub, with that hub.
I have multiple cards from multiple manufacturers to test with here, so I doubt they would all have the same hardware flaw.
I too had considered the possibility of bad card readers, but since I'm unable to make it fail under 2.4.x, I can only assume that it is a bug in the USB (or SCSI?) code in 2.6.x. Possibly it is a badly behaving device that 2.4.x never cared about, but 2.6.x is much more strict?
In this log clip below, you can see that after inserting the card for the last time before deadlock, at least one bulk xfer is sucessful (31 of 31 bytes), but the next command fails (0/36).
Jun 22 18:51:02 light kernel: usb-storage: Bulk Command S 0x43425355 T 0xb5 L 36 F 128 Trg 0 LUN 0 CL 6 Jun 22 18:51:02 light kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 22 18:51:02 light kernel: usb-storage: Status code 0; transferred 31/31 Jun 22 18:51:02 light kernel: usb-storage: -- transfer complete Jun 22 18:51:02 light kernel: usb-storage: Bulk command transfer result=0 Jun 22 18:51:02 light kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes Jun 22 18:51:08 light kernel: usb-storage: command_abort called Jun 22 18:51:08 light kernel: usb-storage: usb_stor_stop_transport called Jun 22 18:51:08 light kernel: usb-storage: -- cancelling URB Jun 22 18:51:08 light kernel: usb-storage: Status code -104; transferred 0/36 Jun 22 18:51:08 light kernel: usb-storage: -- transfer cancelled Jun 22 18:51:08 light kernel: usb-storage: Bulk data transfer result 0x4 Jun 22 18:51:08 light kernel: usb-storage: -- command was aborted Jun 22 18:51:08 light kernel: usb-storage: usb_stor_Bulk_reset called
Somewhere in the 6 second gap between
Jun 22 18:51:02 light kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 36 bytes and Jun 22 18:51:08 light kernel: usb-storage: command_abort called
is there a way to get more debug output?
Regards, Ian Morgan
-- ------------------------------------------------------------------- Ian E. Morgan Vice President & C.O.O. Webcon, Inc. imorgan at webcon dot ca PGP: #2DA40D07 www.webcon.ca * Customized Linux Network Solutions for your Business * -------------------------------------------------------------------
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel