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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
