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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
