On Fri, Nov 07, 2003 at 11:21:48AM -0500, Alan Stern wrote: > On Fri, 7 Nov 2003, Dmitri Katchalov wrote:
> > I investigated it a little and that's what I found: > > This device uses CB transport (SENSE status not reported). > > This device does not support MODE_SENSE at all. > > MODE_SENSE(6) fails with STALL condition. Subsequent > > REQUEST-SENSE reports ILLEGAL REQUEST. SCSI layer is > > able to handle this situation, the only drawback is > > that write-protect status is not reported. > > > > Unfortunately usb-storage sets use_10_for_ms flag > > by default which causes SCSI to try MODE_SENSE(10) > > first. > > The device responds to MODE_SENSE(10) with "babble" > > (-EOVERFLOW). scsiglue sees transport error and > > tries to do a soft reset (which also fails). > > Note that scsiglue does not automatically send > > REQUEST-SENSE in this case. > > > > scsiglue then gives up after several attempts and > > reports the error to the upper layer. Upper layer > > (SCSI) correctly realises that MODE_SENSE(10) does > > not work and attempts to fallback to MODE_SENSE(6) > > but before that it issues TEST_UNIT_READY. > > This time the device responds with ILLEGAL REQUEST. > > Now SCSI gets totally confused and decides to give up. The above sequence is not quite correct (assuming the same behaviour as logs for another failing Sony/Sony DSC), the MODE SENSE goes out, but we do not notice in scsi core that it failed (host byte DID_ERROR). The MODE SENSE is treated as if it succeeded, and yes the TEST UNIT READY gets an ILLEGAL REQUEST. I don't recall what happens to further MODE SENSE commands. > > As I understand it this ILLEGAL REQUEST actually refers > > to the previous MODE_SENSE(10) command because this > > error condition has never been cleared properly. > > You're probably right. But that's not how TEST-UNIT-READY is _supposed_ > to behave. It shouldn't be reporting the status from a previous command; > it should indicate the device's current status. > > > If I change interpret_usb_result() in transport.c > > to ignore "babble" then the next REQUEST-SENSE > > reports ILLEGAL REQUEST, SCSI handles that and > > everything sort of works. I don't see how that worked, I would expect nearly the same command sequence, since scsi core is not checking the error. USB storage debug logs are needed to verify what happened (when ignoring babble/overflow). > > Regards, > > Dmitri > > Patrick, what do you think about implementing that change to have the > response checker retry when it gets ILLEGAL REQUEST from a > TEST-UNIT-READY? No, since we should fix scsi_status_is_good, and then we see a different failure mode for the Sony/Sony DSC. Dmitri - Reference to the patch and discussion about scsi_status_is_good change, you will likely get the same bad result if you apply the patch: http://marc.theaimsgroup.com/?t=106744619500004&r=1&w=2 We should figure out what commands work for the device using SG_IO, try using Pat L's plscsi or modify one of the sg_util programs to send the exact failing command, reference: http://marc.theaimsgroup.com/?l=linux-scsi&m=106755844319144&w=2 A USB trace under Windows would be helpful. -- Patrick Mansfield ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
