Alan, firstly. Thanks. I really appreciate you're looking at this. On 9 Jan 2012, at 22:37, Alan Stern wrote: > 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? DR was explaining stuff about 'known unknowns' and 'unknown unknowns'. His description has been widely quoted and unreasonably lambasted. [snip] > > 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. 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? > >> 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. ok. > >> - 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. > >> - 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. unfortunately, there's nothing of mine in the set up: COTS inverter, no software on the linux box that I've installed. If I controlled the s/w, there'd be a lot more test points in there and I'd understand the protocol much better. > >> - 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. 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. 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? 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. If the issue's the userspace code that's trying to talk to the TI3410, then I've got to find and excise it. > > 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
