On Thu, 12 Jan 2012, Tim Coote wrote: > Alan, > firstly. Thanks. I really appreciate you're looking at this. You're welcome. > > I don't think that will help. It will be better if you can figure out > > what program is talking to the TUSB3410 device and what it's doing. > > Apparently that program is the cause of your difficulties. > > There's nothing running on the linux box that I can identify > immediately. This log's from a fedora 15 build. I've not knowingly > added anything that's trying to talk to any USB device. That said, I > think the distros do tend to include stuff like modem drivers which > seem to interrogate usb insertions. I should get my f16 build up > again and see if that's doing anything odd as I've pulled modem > drivers out of that. Have you got any suggestions on how to spot > what's interacting with the TUSB3410 serial controller? 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. 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. > >> - why does the failing interaction not complete when it does get to > >> device 2 (at around sample 21283) > > > > At that time the device number is 5, not 2. The interaction doesn't > > complete because the device disconnects itself, presumably for lack of > > power. > I cannot understand the protocol well enough: according to wireshark > 21282 is a host -> device 0 SET ADDRESS command with a Device address > of 2. So it is. If you look carefully through the log, you'll see that 68 is SET ADDRESS with address 3, 152 is for address 5, 234 is for address 7, 312 is for address 9, 392 is for address 11, ..., 9866 is for address 81, 10058 is for address 82, ..., 20688 is for address 126, and 20984 is for address 127. Each time the device reconnects it gets assigned the next address. The maximum address is 127, 0 is not a valid address, and 1 is already in use. Therefore after 127, the value wraps back to address 2. > > It's only one device. The device number keeps changing because the > > system increments it every time there's a new connection. You get > > lots of new connections because the device runs out of power every few > > seconds. > 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. 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
