On 13 Jan 2012, at 15:34, Alan Stern wrote: > On Thu, 12 Jan 2012, Tim Coote wrote: > >> Alan, >> firstly. Thanks. I really appreciate you're looking at this. > > You're welcome. > [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. > > 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. Ok. I've got another linux box available now (fedora 16), I'll work with that and try those thoughts (+ I'll redo the power up dump to ensure that nothing's changed too dramatically). [snip] >>>> > > 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. > [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. ok. > >> 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. Well, I could if I just used Win XP - which seems to work ok - but I'd have a pig of a job automating a gui app and I'd need to life with the crummy data that the native app captures. > > 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. I cannot realistically do this. It's a sealed unit (costing several hundred quid). My current hypothesis, based on this thread, is that if I pull out whatever's trying to talk to the damned thing while it's under powered, it ought to come up, and I can then simply start logging after the sun's well and truly up. > >> 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. ok. but I will tonight as it's powered down :-) > > 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
