On Tue, 14 Sep 2010, Toby Gray wrote: > Hi, > > I've been looking at some issues with some disconnection issues seen > when using Barry (http://barry.sourceforge.net) to communicate with some > BlackBerry devices. > > The underlying problem seems to be that the BlackBerry device fails to > respond to a Test Unit Ready SCSI command within the timeout period. > This causes the usb-storage driver to reset the USB device when handling > the timeout in usb_stor_invoke_transport(), which causes the Barry > communications on other endpoints to fail. > > A sample of the output from usb_storage with debugging enabled is: ... > My question therefore is if it is necessary to always reset the USB > device when a usb-storage command times out? It is pretty much the only choice. There is a class-specific reset but it almost never works (probably because Windows doesn't use it). > If there are other alternatives to resetting the whole device then could > someone give me a few suggestions to point me in the right direction? The class-specific reset is implemented by us->transport_reset(us) in the usb-storage driver. > The BlackBerry continues to communicate correctly on the other endpoints > while the usb-storage command is pending and when I tried a nasty hack > of just commenting out the resetting of the USB device so that the SCSI > layer could retry the command then it at least seems like the BlackBerry > can recover, with usb-storage and Barry continuing to work correctly. > I'm not suggesting that this hack is anything like a solution, but was > curious to see if the hanging command could be recovered from. That's unusual. Normally if a command hangs like that, the device won't respond to anything until it is reset (and maybe not even then). Perhaps a better question is why the Blackberry fails to respond to the TEST UNIT READY command in the first place. Alan Stern -- 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
