On 19 Dec 2011, at 20:55, Alan Stern wrote: > On Mon, 19 Dec 2011, Tim Coote wrote: > >> No. But it does describe how the host drivers can confuse devices. >> And my experience of such devices is that, for instance, they can be >> swamped with error conditions that causes a stack overflow. Any I'm >> hypothesising that's what's happened here. > > No need to hypothesize. Look at the actual data from usbmon or > wireshark and see what's really happening. > Ok. I'll try to set that up. But it will still not tell me what's going on inside the device. >>> echo X >/sys/bus/pci/drivers/uhci_hcd/unbind >>> >>> Replace X with the correct name of the UHCI device for the bus your >>> device is plugged into -- this will be one of the file names in the >>> /sys/bus/pci/drivers/uhci_hcd directory, such as 0000:00:1d.1. >>> >>> To rebind the controller, use the same command but replace "unbind" >>> with "bind". >> Thanks. This does seem to work. However, this did not solve the problem the first time (I unbound what I thought was the correct device, but I can see that it could simply be the wrong one, so I'm going to disable them all tonight. >> >> Are there any instructions on how these types of commands work. I've found something on lwn, but it misses the context of what the different connections can be. > > These's lots of documentation about these things in the Linux kernel > source's Documentation directory. In particular, the unbind and bind > files are explained in Documentation/ABI/testing/sysfs-bus-pci > (although they apply to all buses now, not just PCI). > Thanks, I'll read that. When I unbind all of the devices, I don't get the errors. But then again, I don't think that the /dev/ttyUSB0 device gets created (nss!) So this is at best a partial work around for me, as I'd like to get to the device as soon as it boots up. I'll setup the usbmon capture tonight. Looking at the /var/log/messages difference for the failed connections vs the ones that work, there does seem to be a difference in the code that's executed: Here's a broken attempt to communicate with the device (as the inverter's booting up): Dec 19 07:43:03 pluto kernel: [143649.474044] usb 3-2: new full speed USB device number 14 using uhci_hcd Dec 19 07:43:03 pluto kernel: [143649.704115] usb 3-2: New USB device found, idVendor=0451, idProduct=3410 Dec 19 07:43:03 pluto kernel: [143649.704124] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 19 07:43:03 pluto kernel: [143649.704132] usb 3-2: Product: TUSB3410 Boot Device Dec 19 07:43:03 pluto kernel: [143649.704138] usb 3-2: Manufacturer: Texas Instruments Dec 19 07:43:03 pluto kernel: [143649.704144] usb 3-2: SerialNumber: TUSB3410 Dec 19 07:43:03 pluto kernel: [143649.708242] ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected Dec 19 07:43:03 pluto kernel: [143649.730125] usb 3-2: ti_download_firmware - error downloading firmware, -75 Dec 19 07:43:03 pluto kernel: [143649.730151] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5 Dec 19 07:43:03 pluto kernel: [143649.730282] hub 3-0:1.0: port 2 disabled by hub (EMI?), re-enabling... Dec 19 07:43:03 pluto kernel: [143649.730292] usb 3-2: USB disconnect, device number 14 Dec 19 07:43:04 pluto kernel: [143649.886072] hub 3-0:1.0: unable to enumerate USB device on port 2 and here's one that succeeds (from after the inverter's fully booted): Dec 18 12:16:04 pluto kernel: [73629.951045] usb 3-2: new full speed USB device number 2 using uhci_hcd Dec 18 12:16:04 pluto kernel: [73630.159119] usb 3-2: New USB device found, idVendor=0451, idProduct=3410 Dec 18 12:16:04 pluto kernel: [73630.159129] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Dec 18 12:16:04 pluto kernel: [73630.159136] usb 3-2: Product: TUSB3410 Boot Device Dec 18 12:16:04 pluto kernel: [73630.159142] usb 3-2: Manufacturer: Texas Instruments Dec 18 12:16:04 pluto kernel: [73630.159148] usb 3-2: SerialNumber: TUSB3410 Dec 18 12:16:04 pluto kernel: [73630.557559] USB Serial support registered for TI USB 3410 1 port adapter Dec 18 12:16:04 pluto kernel: [73630.558451] USB Serial support registered for TI USB 5052 2 port adapter Dec 18 12:16:04 pluto kernel: [73630.559250] ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected Dec 18 12:16:04 pluto kernel: [73630.559291] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5 Dec 18 12:16:04 pluto kernel: [73630.560301] usbcore: registered new interface driver ti_usb_3410_5052 Dec 18 12:16:04 pluto kernel: [73630.560308] ti_usb_3410_5052: v0.10:TI USB 3410/5052 Serial Driver Dec 18 12:16:04 pluto kernel: [73630.562244] ti_usb_3410_5052 3-2:2.0: TI USB 3410 1 port adapter converter detected Dec 18 12:16:04 pluto kernel: [73630.562980] usb 3-2: TI USB 3410 1 port adapter converter now attached to ttyUSB0 Is it likely to be significant that during the failed log entries, it looks like the ti_usb_3410_5052 driver detects an adapter much faster than in the successful case (~0.04 sec vs ~0.4 sec), and never gets to the successful registration of the port adapter? > Alan Stern > Tim-- 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
