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. 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. > > > kernel: usb 1-1.1.6.1: new full-speed USB device number 21 using ehci-pci > > > kernel: usb 1-1.1.6.1: device descriptor read/64, error -110 > > > kernel: usb 1-1.1.6.1: device descriptor read/64, error -110 > > > kernel: usb 1-1.1.6.1: new full-speed USB device number 22 using ehci-pci > > > kernel: usb 1-1.1.6.1: device descriptor read/64, error -110 > > > kernel: usb 1-1.1.6.1: device descriptor read/64, error -110 > > > kernel: usb 1-1.1.6.1: new full-speed USB device number 23 using ehci-pci > > > kernel: usb 1-1.1.6.1: device not accepting address 23, error -110 > > > kernel: usb 1-1.1.6.1: new full-speed USB device number 24 using ehci-pci > > > kernel: usb 1-1.1.6.1: device not accepting address 24, error -110 > > > kernel: hub 1-1.1.6:1.0: unable to enumerate USB device on port 1 > > > > At this point the device never gets back to the bus itself. Either the whole hardware has to be power-cycled or the USB cable detached and attached again. > > > > The device is connected as follows (if done correctly) > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M > > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M > > |__ Port 6: Dev 14, If 0, Class=Hub, Driver=hub/1p, 480M > > |__ Port 1: Dev 16, If 0, Class=Vendor Specific Class, Driver=, 12M > > > > Now the funny thing: This doesn't occur if > > 1. The device with its internal hub (Dev 14 above) is attached to xHCI host > > 2. There is an Full-Speed-Hub before the device > > 3. The device is attached to a OHCI host > > > > The error occurs about 3-6 min after start while the test cases where it didn't happen run for longer than 1 hour. > > > > 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. 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
