On Mon, 9 Jan 2012, Tim Coote wrote: > Ah, a Rumsfeld scenario. Sorry, I don't get the reference. Which of Rumsfeld's escapades are you referring to? > Very gracious: thanks. Here's: > a/ a file created by listening on wireshark to the usb 2.0 bus > starting the night before, stopping after the interactions ceased and > confirming that the Inverter was not working, even with XP: > http://dl.dropbox.com/u/10589123/usbBus2OvernightConnectionWillNotRecoverWithXpCannotFindSerialNumberOnAnyAddress Okay. To begin with, this log shows a bunch of attempts to initialize the TUSB3410 boot device which all fail at various different points, probably because the device isn't getting enough power. But eventually it seems to settle down. Following that there appear to be a lot of firmware transfers. They have differing lengths because the device disconnects itself in the middle. Finally, starting at index 46412 is a firmware transfer that gets through to the end -- but the device still disconnects itself. Probably still not getting enough power. Not until index 85236 does the device get all the through the firmware reload. The system sets the device to config 1, then some program sets it to config 2 and asks for various string descriptors. When it asks for descriptor 0xee twice, the device again disconnects itself. The log shows that this was not caused by lack of power -- it looks like the device simply can't handle that request. This just keeps on repeating, over and over. The program asks for that descriptor and the device disconnects. > b/ for comparison, a wireshark monitoring session spanning connecting > to the Inverter when already > booted:http://dl.dropbox.com/u/10589123/usbBus2AsPviConnected This log shows somewhat different behavior on the part of the program talking to the device. It asks for the string descriptors only once, while the device is still in config 1, and then switches to config 2. Apparently the device doesn't mind this so much, and it keeps on working. > If it's of any value, I can try to grab a suitable xp tool to get the > interaction on that box. USBlyzer looked the most suitable to me > (http://bit.ly/zrPuLA) 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. > The data raise a few questions in my mind, which I'm afraid I don't > have the background to even say whether they are relevant: > - why does the failing interaction start by interrogating device 3, > whereas the one from just plugging in the usb cable starts at device > 2 Because in the failing log, the device starts out getting so little power that it disconnects even before the system can tell it to use address 2. > - 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. > - what causes the succeeding interaction to stop I don't know. It's your program; don't you know why it stops transmitting data? Maybe it reaches the end and exits. > - why do so many devices from the failing interaction report that > they exist 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. 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
