On 15/09/2010 19:30, Alan Stern wrote:
On Wed, 15 Sep 2010, Toby Gray wrote:
On 15/09/2010 15:27, Alan Stern wrote:
On Wed, 15 Sep 2010, Toby Gray wrote:
...
Thanks for pointing me towards that. Is there any reason why
usb_stor_invoke_transport tries to reset the port before trying the
class-specific reset method? Other than the extra 5 second wait on every
timeout while it tries to send the Command Block Reset.
Because the class-specific reset almost never works and because Windows
doesn't use it. As I mentioned in the previous email.
Sorry, I didn't explain my question very well. My question probably
should have been: as the class-specific reset almost never works, is the
only reason to attempt it after a port reset has failed is because it's
better than doing nothing? You're most recent response to Anand Gadiyar
has answer this though.
"Better than doing nothing" pretty much sums it up. If you can't reset
the device then you're stuck, one way or another.
Coming back to the point you made in your original reply about why the
BlackBerry fails to respond to TEST UNIT READY, it appears to be that on
Windows, TEST UNIT READY queries are never sent to the device.
Not so. I have logs taken using hosts running Windows 2000, Windows
XP, and Windows Vista, all containing TEST UNIT READY commands.
The situation which I'm testing is when the BlackBerry doesn't contain a
memory card. When there's no memory card in the BlackBerry, the
BlackBerry (incorrectly) fails the READ FORMAT CAPACITIES command that
Windows attempts to issue immediately after the initial INQUIRY. The
REQUEST SENSE for the BlackBerry indicates that there is no media in the
device. If there is a memory card in the BlackBerry then the READ FORMAT
CAPACITIES succeeds and Windows XP does, as you say, send TEST UNIT
READY queries.
So in trying to track down the reason for the TEST UNIT READY query on
Linux I think it's probably down to either the READ FORMAT CAPACITIES
causing some different code paths to be taken in the device firmware or
just a simple timing issue which the Windows USB stack doesn't expose.
Either way there doesn't seem to be a straightforward way to try to
implement a workaround to avoid the TEST UNIT READY hang in Linux.
Therefore I'm just going to go ahead with the class-specific reset fix
as that doesn't disrupt Barry's use of the USB and avoids usb-storage
data loss, at the expense of a 30 second pause.
Windows
seems to use READ FORMAT CAPACITY followed by REQUEST SENSE to determine
if media is present, but I'm going to have a look at this in more detail.
Assuming that is what Windows does, would a better solution be to add a
flag for faking TEST UNIT READY commands as a READ FORMAT CAPACITY
followed by REQUEST SENSE (or however Windows seems to do it)? Or would
you say that having a flag for trying class-specific reset first is a
better solution?
The TEST UNIT READY commands get generated in a few different spots.
Changing them would be harder than adding a simple flag to usb-storage.
Yes, I noticed that when I looked a bit deeper into the SCSI driver. I
also realised that attempting to add support for READ FORMAT CAPACITIES,
even as just a hack to see if it helped, was going to be quite a bit of
work.
Alan Stern
Thanks for all your help and comments, they've really helped me
understand what's going on.
Regards,
Toby
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
