On 13 Jan 2012, at 15:34, Alan Stern wrote: [snip] > > It may be something like usb_modeswitch, or a program invoked by a udev > rule. Or it could be a modem manager. > > Something that might help is to enable the usbfs_snoop module parameter > for usbcore before plugging in the device: > > echo 1 >/sys/module/usbcore/parameters/usbfs_snoop > > That will add a bunch of output to the system log, including the names > of programs that directly access USB devices. Here's what I got: Jan 14 10:50:49 pluto kernel: [ 4622.452049] usb 3-2: new full speed USB device number 2 using uhci_hcd Jan 14 10:50:49 pluto kernel: [ 4622.684080] usb 3-2: New USB device found, idVendor=0451, idProduct=3410 Jan 14 10:50:49 pluto kernel: [ 4622.684089] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 14 10:50:49 pluto kernel: [ 4622.684097] usb 3-2: Product: TUSB3410 Boot Device Jan 14 10:50:49 pluto kernel: [ 4622.684102] usb 3-2: Manufacturer: Texas Instruments Jan 14 10:50:49 pluto kernel: [ 4622.684108] usb 3-2: SerialNumber: TUSB3410 Jan 14 10:50:50 pluto kernel: [ 4623.150995] USB Serial support registered for TI USB 3410 1 port adapter Jan 14 10:50:50 pluto kernel: [ 4623.151213] USB Serial support registered for TI USB 5052 2 port adapter Jan 14 10:50:50 pluto kernel: [ 4623.151255] ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected Jan 14 10:50:51 pluto kernel: [ 4623.788052] usb 3-2: reset full speed USB device number 2 using uhci_hcd Jan 14 10:50:51 pluto kernel: [ 4623.918079] usb 3-2: device firmware changed Jan 14 10:50:51 pluto kernel: [ 4623.918117] usb 3-2: USB disconnect, device number 2 Jan 14 10:50:51 pluto kernel: [ 4623.918144] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5 Jan 14 10:50:51 pluto kernel: [ 4623.919413] usbcore: registered new interface driver ti_usb_3410_5052 Jan 14 10:50:51 pluto kernel: [ 4623.919420] ti_usb_3410_5052: v0.10:TI USB 3410/5052 Serial Driver Jan 14 10:50:51 pluto kernel: [ 4624.023049] usb 3-2: new full speed USB device number 3 using uhci_hcd Jan 14 10:50:51 pluto kernel: [ 4624.232076] usb 3-2: New USB device found, idVendor=0451, idProduct=3410 Jan 14 10:50:51 pluto kernel: [ 4624.232086] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 14 10:50:51 pluto kernel: [ 4624.232094] usb 3-2: Product: TUSB3410 Boot Device Jan 14 10:50:51 pluto kernel: [ 4624.232100] usb 3-2: Manufacturer: Texas Instruments Jan 14 10:50:51 pluto kernel: [ 4624.232106] usb 3-2: SerialNumber: TUSB3410 Jan 14 10:50:51 pluto kernel: [ 4624.235195] ti_usb_3410_5052 3-2:1.0: TI USB 3410 1 port adapter converter detected Jan 14 10:50:51 pluto kernel: [ 4624.235223] ti_usb_3410_5052: probe of 3-2:1.0 failed with error -5 Jan 14 10:50:51 pluto kernel: [ 4624.239194] ti_usb_3410_5052 3-2:2.0: TI USB 3410 1 port adapter converter detected Jan 14 10:50:51 pluto kernel: [ 4624.239743] usb 3-2: TI USB 3410 1 port adapter converter now attached to ttyUSB0 > > Also, if you unplug the device, reboot, and plug the device back in > then the system log may include the name of a driver module that was > automatically loaded to handle the device. the diff between lsmod of a cleanly booted machine and then plugging in the fully powered up Inverter is: < tcp_lp 2211 0 < ti_usb_3410_5052 21110 0 So, I'd guess that the offending driver is ti_usb_3410_5052. If I understand your description of the initiation process, that driver is being installed as a result of some other program that I've yet to track down. And dbus is a likely starting point for running the program, possibly related to tcp_lp (whatever that is, and I note that it's not dependant on the other driver). I think that ti_usb_3410_5052 does try to load firmware. > > [snip] >> So the device number's irrelevant. If I understand you correctly, you >> feel that there's something trying to talk to the device, which >> probably causes it to run out of power, drop the connection, which >> almost immediately creates a new connection. > > Not exactly. The initial communication is just the normal start-up and > enumeration that every USB device has to go through when it connects to > a computer. At first, even that is enough to cause the device to run > out of power. Later on, something sends new firmware to the device, > and that causes it to run out of power. It's only toward the end of > the log, when there's enough power for the device to keep running > through the entire initialization and firmware installation, that we > see some genuine crashes -- and those crashes do not appear to be > power-related. > >> Is there an easy way to >> write something else that would spot the usb connection coming up and >> then simply grab the device and wait for a while for the power to >> come up? > > No. This is a hardware problem; you can't solve it with software. > > Maybe you can find something that will disconnect the TUSB device from > its power source whenever the inverter isn't supplying enough current. > Or maybe you can just run it off a battery, or add a large capacitor to > the power circuit. > >> It sounds like I: >> a/ need to find what's talking to the usb device (and I'm not sure how to do this yet). >> b/ confirm that if nothing talks to the device, it eventually boots up. > > The second one isn't necessary; the log shows that the device did > eventually boot up. Several times, in fact. But then it crashed > because something sent it a request it couldn't handle. > >> If the issue's the userspace code that's trying to talk to the >> TI3410, then I've got to find and excise it. > > Yes. Bear in mind that you don't have to wait for sunrise to do this. > Each time you unplug and replug the USB connection, that program will > try to talk to the device. > so I should try winding up the log output on dbus and looking to see what it's doing as the usb's pushed in. > Alan Stern > -- 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
