On Tue, 22 Jun 2004, Ian E. Morgan wrote:
> On Tue, 22 Jun 2004, Alan Stern wrote:
>
> > 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).
No, it is the first command. Transferring a command involves 2 or 3
phases: the command phase, the optional data phase, and the status phase.
The successful 31-byte transfer was the command phase; that doesn't
require the reader to actually communicate with the card. The
unsuccessful 36-byte transfer was the data phase.
> 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?
You mean the same sequence of commands will fail sometimes in 2.6 but not
in 2.4? That's very strange. And no, this isn't a question of 2.6 being
more strict about some marginal device. When Linux tries to send a
command to the reader and there is _no response at all_, you can't call
that being strict.
It's much more likely that the same failure occurs in 2.4, but the bus
reset code there works better than in 2.6 so you recover without deadlock.
> 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?
No. And there isn't anything you could learn anyway. The command was
sent to the reader and we are waiting for it to send its response.
Everything is perfectly normal, it's just that the reader doesn't respond.
Just as a test, you might try applying the patch below. It will slow down
throughput, but if it gets the reader to work that's at least a start.
Alan Stern
===== drivers/usb/storage/usb.c 1.119 vs edited =====
--- 1.119/drivers/usb/storage/usb.c Sun Jun 13 16:09:07 2004
+++ edited/drivers/usb/storage/usb.c Mon Jun 21 10:51:41 2004
@@ -359,6 +359,7 @@
/* we've got a command, let's do it! */
else {
US_DEBUG(usb_stor_show_command(us->srb));
+ msleep(2);
us->proto_handler(us->srb, us);
}
-------------------------------------------------------
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
