Alan Stern wrote:
Sorry about that! I try to give credit where it's due. It's good work and has fixed my problem and the problems of at least two other people!On Sun, 27 Jun 2004, Phil Brunner wrote:
The attached Matthew Dharm patch
Just to set the record straight, I wrote the majority of that patch. It was submitted to Matt Dharm, who changed it slightly by making the option to use the MODE SENSE command selectable in the kernel configuration.
For example, on lkml, Roland Lezuo asked for any patch that might fix his problem with his Traxdata EZ drive -- see:
usb-storage, sd_mod problem, with debugging infos ;) on lkml on 6/23/04
His debug output looked very similar to mine; so, I sent him your patch -- and it worked!
Since Windows asks for 192 bytes and most/all devices are designed to work with Windows, it would probably be a good idea to ask for 192 bytes by default for Linux USB. If this were done, then we could avoid the case where a new/unrecognized device (such as my smartcard reader) brings down the hub due to babble. Perhaps we need a "whitelist" which reduces length values for unambiguously identified devices to improve efficiency?(which should probably be in 2.6.8
per Alan Stern) fixed the problem for 2.6.5, 2.6.6 and all 2.6.7 varieties. There were no problems with 2.6.4.
The patch seems to make the MODE_SENSE command (try to) transfer 192 bytes rather than 4 bytes - results in "babble" since actual transfer length seems to be 8. After the data overrun, various combinations of [khubd], [usb-storage], and [scsi_eh_?] deadlock and the hub is effectively dead; attempted resets don't work.
Alan, I continue to look at this without much success and no consistency.
The one thing that seems consistent is that the babble (and subsequent software failures) always occur after a MODE_SENSE that requests 4 bytes; and my hardware returns 8 bytes; e.g.:
Jun 22 19:40:33 darkstar kernel: usb-storage: Command MODE_SENSE (6 bytes)
Jun 22 19:40:33 darkstar kernel: usb-storage: 1a 00 3f 00 04 00
Jun 22 19:40:33 darkstar kernel: usb-storage: Bulk Command S 0x43425355 T 0x23 L 4 F 128 Trg 0 LUN 0 CL 6
Jun 22 19:40:33 darkstar kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 22 19:40:33 darkstar kernel: usb-storage: Status code 0; transferred 31/31
Jun 22 19:40:33 darkstar kernel: usb-storage: -- transfer complete
Jun 22 19:40:33 darkstar kernel: usb-storage: Bulk command transfer result=0
Jun 22 19:40:33 darkstar kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 4 bytes
Jun 22 19:40:33 darkstar kernel: usb-storage: Status code -75; transferred 4/4
Jun 22 19:40:33 darkstar kernel: usb-storage: -- babble
Right. A lot of devices aren't careful about sending too much data. They probably expect always to be asked for 192 bytes, which is what Windows does.
The way the Dharm's patch seems to work for me is to cause the MODE_SENSE to request 192 bytes - results in a short reply but that seems not to matter:
Jun 22 20:28:49 darkstar kernel: usb-storage: Command MODE_SENSE (6 bytes)
Jun 22 20:28:49 darkstar kernel: usb-storage: 1a 00 3f 00 c0 00
Jun 22 20:28:49 darkstar kernel: usb-storage: Bulk Command S 0x43425355 T 0x25 L 192 F 128 Trg 0 LUN 0 CL 6
Jun 22 20:28:49 darkstar kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
Jun 22 20:28:49 darkstar kernel: usb-storage: Status code 0; transferred 31/31
Jun 22 20:28:49 darkstar kernel: usb-storage: -- transfer complete
Jun 22 20:28:49 darkstar kernel: usb-storage: Bulk command transfer result=0
Jun 22 20:28:49 darkstar kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 192 bytes
Jun 22 20:28:49 darkstar kernel: usb-storage: Status code 0; transferred 8/192
Jun 22 20:28:49 darkstar kernel: usb-storage: -- short transfer
Jun 22 20:28:49 darkstar kernel: usb-storage: Bulk data transfer result 0x1
Right again. Short replies are normal and expected.
So, asking for 192 bytes is safe.
From what you've told me, it sounds like Windows "turns off " the shutdown feature by always requesting 192 bytes and avoiding the babble entirely.
Is it possible that the 8 byte return (when 4 were requested) overruns a buffer somewhere and clobbers some data, resulting in subsequent errors? This is the only type of error I can think of that might explain the observed erratic behavior.
No, buffers don't get overrun and nothing is clobbered. In itself that error doesn't really matter much -- all it would mean is that Linux wouldn't know whether the medium was write protected.
What actuall can happen is a lot worse than that. USB host controllers made by VIA Technologies have a handy "feature" of shutting themselves off whenever they encounter "babble"! All it takes is one bad packet and that's it -- no more USB communications through that controller until it is fully reset.
This problem doesn't arise under Windows. Apparently VIA's controller
driver for Windows manages to turn off this shutdown feature. I sure
would like to know how they do it! But VIA isn't talking.
Not really, but I'm used to it! (Especially when dealing with hardware where timing or the unpredictable state of the system can alter results.)As for Ian Molton's problem, that's a different story. I have no idea why that patch fixed things for him.
I believe I saw an 8-byte MODE_SENSE request in 2.6.4 (which didn't have the problem) but can not reproduce this. Also, I have been unable to reproduce the Medium not present errors I saw in one test!
And I have not recently found a case where the MODE_SENSE is sent at all when everything is working.
Don't you love it when bugs or solutions fail to be reproducible?
Alan Stern
Thanks again for taking the time to help me with this. Phil
-------------------------------------------------------
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
