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. > (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. > 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. 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 ------------------------------------------------------- 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
