On Wed, 23 Jun 2004, Alan Stern wrote:
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.
Ah.. now I understand.. Thanks for the education.
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.
I can't yet confirm the "same sequence of commands". I haven't bothered to rebuild Fedora's ugly 2.4 kernel with USB debugging, since it works under 2.4 without deadlocks.
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.
I would have expected to see delays then as the bus was being reset, but there isn't any.
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.
If that was really all there was too it, then I would expect that disconnecting the reader from the USB and removing power from the reader should cause things to be 'reset' to cold power-up state. But after doing that, the USB subsystem is still dead, and plugging the devices back in and powering them up still does not allow the subsystem to recover. The [scsi_eh_n] thread stays in "D" state indefinitely, and I must reboot to clear it.
When the subsystem is locked, and I unplug the reader, I start getting:
Jun 23 12:00:36 light kernel: uhci_hcd 0000:00:1d.0: suspend_hc Jun 23 12:00:36 light kernel: uhci_hcd 0000:00:1d.0: wakeup_hc
over and over (about every 2-3 seconds) in the logs, until I reattach the reader, then it stops, but the subsystem is still otherwise locked and no other debugging messages appear. This is without a hub between the device and host.
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.
===== 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); }
No effect. It still deadlocks. Just for fun I also tried it with with msleep(100) and still it deadlocks.
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
