On Sat, 8 Nov 2003, Patrick Mansfield wrote: > On Sat, Nov 08, 2003 at 11:28:37AM -0500, Alan Stern wrote: > > > The "fake sense" is a compromise. It lets us give a clear indication to > > the higher layers that something is wrong and asks them not to send the > > same command again. But it doesn't do much about getting the device back > > into a working state (if that's even possible). > > Looking closer at the USB code, is the fake_sense code even hit? The logs > do not show any of the US_DEBUGP in usb_stor_Bulk_transport(), like > "Bulk Command S ...".
It probably wasn't hit. The fake sense data is only sent for devices using the Bulk-only transport, and Dmitri's and Idan's devices use the Control-Bulk transport IIRC. > A DID_ERROR causes scsi core to retry the command - it will not even check > the sense data. A DID_ABORT might be better, scsi core will not retry. > (We still have issue 1, where the host byte is not checked in > scsi_status_is_good.) For CB and CBI devices, babble causes a DID_ERROR return. For Bulk-only it causes a Check-Condition status to be returned along with Invalid Command sense data. Like I said earlier, we haven't yet figured out the best way to handle these errors. > > > That still doesn't tell us why the MODE SENSE failed, and why the failure > > > does not show up with 2.4. > > > > The best approach for doing this is to have a side-by-side comparison of > > the usb-storage debugging logs for 2.4 and 2.6. > > Yes, we do not have a 2.4 trace of the same device. > > > I think we have to assume > > that the MODE-SENSE failed because the device simply doesn't support it > > correctly. > > > > > Can you run the variants on MODE SENE via user space SG_IO, and figure out > > > which ones work? > > Still no data on the above (from Dmitri or Ronald). Doing that will probably be a waste of time. I firmly believe that there is _no_ least common denominator among USB mass storage devices: Some work with any MODE-SENSE command, some work with only a few variants, others work with others. Maybe some devices don't work with MODE-SENSE at all. In any case, there isn't any single combination of pages/transfer-lengths that will be accepted by every device. And when a device fails to accept such a command it often does so catastrophically, requiring a power-cycle to start working again. The only safe course is to avoid sending these commands at all to the devices that can't handle them. > > > 3) The next command - TEST UNIT READY - gets a check condition, illegal > > > request. Maybe the fake sense handling is screwing things up - the device > > > tells us it sent back more data than we asked for, but it is also trying > > > to check us. > > > > I don't understand your speculation here. It seems clear to me that this > > is a situation where the device and the host are out of sync -- the host > > sends a command and the device sends back status from the _previous_ > > command. Repeating the TEST-UNIT-READY may bring us back in sync. Or > > maybe some sort of reset will -- no way to tell without trying it. > > The sense data is not cleared until it is retrieved, so if there is sense > waiting, and we do not send a REQUEST SENSE, the next REQUEST SENSE will > retrieve the pre-existing sense data (see SAM-3, I am looking at > sam3r07.pdf, section 5.9.6 sense data). Hmmm... I'm more used to an earlier version of the SCSI protocol, according to which old sense data is lost whenever a new command is received unless that command is REQUEST-SENSE. > If the actual result of the command was checked in the babble cases, and a > REQUEST SENSE sent, it might have gotten the ILLEGAL REQUEST, and the > devices sense data might be cleared. It might be bad to do anything for > babble cases, but the REQUEST SENSE should be sent to at least clear out > any real sense data if we are going to generate our own fake sense. There's isn't any reliable way to get the command result or the sense data after a babble occurs -- in fact, there isn't a reliable way to re-establish communication with the device at all. My best thought on this has been to try reading (and throwing away) data from the device until a 5-second (for example) timeout expires without receiving anything, then issue a device reset. That's more likely to recover from this sort of error than anything else I can think of, but it's never been implemented. I have seen logs from users where a device reset was sent following a babble error. It didn't help; the device remained wedged. The USB Mass Storage specification documents are silent on the issue of babble. And even if they weren't it probably wouldn't help; the only reason these devices start babbling is because they aren't compliant with the standards in the first place. > Dmitri's change (return USB_STOR_XFER_STALL instead of USB_STOR_XFER_LONG) > causes us to return USB_STOR_TRANSPORT_GOOD vs USB_STOR_TRANSPORT_ERROR in > usb_stor_CB_transport. > > Then in usb_stor_invoke_transport we issue a REQUEST SENSE. > > If for a USB_STOR_TRANSPORT_ERROR we also did a REQUEST SENSE, the > following command (TEST UNIT READY) would not get the ILLEGAL REQUEST. That doesn't make sense. USB_STOR_TRANSPORT_ERROR means we aren't able to communicate with the device. So how can we send it a REQUEST-SENSE? > I don't know why the TEST UNIT READY caused an auto REQUEST SENSE to > be sent. The CB transport doesn't include any means for the device to return status. (Yes, it's stupid.) The only way we can find out is to issue auto REQUEST-SENSE for virtually every command. > Changing the sense stuff does not address the MODE SENSE failing, we still > have 3 separate issues that are all hit by this device. If we simply avoided sending the MODE-SENSE in the first place, none of the other issues would come up. IMHO that's the best solution. Alan Stern ------------------------------------------------------- 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
