On Wednesday 16 October 2013 15:29:53, Alan Stern wrote: > > > > 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? Exactly! > > 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? Yep. But it even works on EHCI if there is a full-speed-hub somewhere before that device. > 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 I tried that but there wasn't any difference. > 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. We tried that but didn't see any USB traffic for those USB device numbers where enumeration failed. One thing about the error log: [249741.159104] usb 2-1.6.1: new full-speed USB device number 109 using ehci-pci [249751.565047] usb 2-1.6.1: device not accepting address 109, error -110 [249751.638197] usb 2-1.6.1: new full-speed USB device number 110 using ehci-pci [249762.044199] usb 2-1.6.1: device not accepting address 110, error -110 [249762.117273] usb 2-1.6.1: new full-speed USB device number 111 using ehci-pci [249777.196292] usb 2-1.6.1: device descriptor read/64, error -110 [249792.376349] usb 2-1.6.1: device descriptor read/64, error -110 [249792.550467] usb 2-1.6.1: new full-speed USB device number 112 using ehci-pci [249807.629330] usb 2-1.6.1: device descriptor read/64, error -110 [249822.809391] usb 2-1.6.1: device descriptor read/64, error -110 [249822.910435] hub 2-1.6:1.0: unable to enumerate USB device on port 1 There are different errors "device not accepting address xxx" and "device descriptor read/64, error -110". Does that mean that reading the device descriptor succeeded when the USB device address shall be set? Alexander -- 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
