On Wed, 16 Oct 2013, Alexander Stein wrote: > On Wednesday 16 October 2013 11:07:50, Alan Stern wrote: > > On Wed, 16 Oct 2013, Alexander Stein wrote: > > > > > Hello, > > > > > > I'm experiencing problems with our USB-CAN-hardware in a test scenario only when being attached to the ehci root-hub. > > > When the device is enumerated and has its USB address the driver is bound and the can interface is started. So far so good. If there is a status request timeout the module firmware disconnects itself from the bus, thus reattaching to the bus, getting a new USB device address and so on... > > > Doing this in a loops lead eventually to this error messages: > > > > Do you have any idea why a status request timeout would occur? Can you > > capture a usbmon trace showing one of these timeouts and the following > > errors? > > I hope status request timeout does not interfere with some USB > standard stuff. In my case this is a safety mechanism in case the > host driver could not get the current status from the device. So the > driver needs to poll from a specific endpoint once a second. I see. So the device itself forces the disconnect if it doesn't receive this status poll sufficiently often, right? > There is no need for usbmon trace. This timeout is intentionally > triggered within the test loop by simply removing the device driver > without shutting down the CAN interfaces. Those dis-/reconnects are > part of the problem I described. > > BTW: There is no shutdown callback for USB device drivers so this > 'problem' even occurs during system reboot when the CAN interface is > not shutdown beforehand. That's true. We could add a shutdown callback, if necessary. Or just unbind all the drivers. > > > So the problem seems to occur only when the hub is connected with high-speed to any hub on an ehci bus. > > > Has somebody an idea what might have gone wrong here? It seems the internal hub has problems with Transaction Translators. But why does this only happen when attached to ehci? Is this maybe a driver problem? > > > I did some tests on 3.11.4 and some on 3.10.7 and both showed same results. > > > > I doubt that it is a driver problem. Much more likely is a bug in the > > internal hub, as you guessed. > > > > This doesn't explain why it works under xHCI but not under EHCI. Do > > you not get any status request timeouts under xHCI? > > Those timeouts are provoked on purpose, so, yes, there also exist in the xHCI case. But with xHCI and OHCI, the reconnect succeeds whereas with EHCI it fails? It's hard to guess why. The behavior under xHCI is slightly different from the other two, which behave the same. You can force EHCI and OHCI to work more like xHCI by doing: echo 1 >/sys/module/usbcore/parameters/old_scheme_first Maybe it's a data toggle issue involving the internal hub, but the only way to find out for sure is to use a bus analyzer. 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
