Well the inverter now seems to come up and want to play. ModemManager is certainly something that I took off the linux box and maybe that's all that was probing the device. So maybe I've reached the point where I'm 'only' debugging the C program that thinks it's talking to a serial device. The device is not as reliable as if it's booted up unconnected to Linux, but I cannot quantify the variation, yet. My guess is that ModemManager was stopping the device dead, but something else is going wrong now (quite possibly the C program, but I wouldn't have thought that it was able to.) I did manage to capture /var/log/messages (now called msg1) from the time of reboot until I managed to run a few tests by hand. I remembered to set up usbfs_snoop. I *think* that this shows that it took a while, but the inverter finally came up as device 91 on bus 3. I also captured a typescript and the wireshark dump. The typescript has some timing information in it, but maybe not enough. I was essentially trying a couple of versions of the commands: /usr/local/bin/aurora -Y 10 -T -a 2 -v /dev/ttyUSB0 This should interrogate the inverter on through the serial port /dev/ttyUSB0 (which is of course the USB device behaving like a serial port, using the ti_usb_3410_5052 kernel module), -a 2 is the address of this particular inverter (dunno why it's 2), -Y 10 should try 10 times to get interrogate the device, -v just returns the devices type (the simplest thing that I think I can ask for. -T prints the current computer time - I should have put this in all commands, but forgot for some. other commands replace the -v with -d 0 or -e, which should return some data on the device status. as far as I can tell, -v usually works (but not always) and -e / -d 0 don't. I don't understand how to interpret the wireshark interactions that are going on, but they do seem to be excessively lengthy. At this stage, just getting a hint as to what's causing the interaction to be less robust than for windows would help. Here's the files: http://dl.dropbox.com/u/10589123/msg1 http://dl.dropbox.com/u/10589123/typescript http://dl.dropbox.com/u/10589123/usb3OverSunUpAndSomeInteractions It is possible to correlate most of the commands in typescript with msg1 and the wireshark file. However, working out what the command is in each case is not always so obvious, I don't think. Tim On 22 Jan 2012, at 16:57, Alan Stern wrote: > On Sun, 22 Jan 2012, Tim Coote wrote: > >> not messianic enough - I forgot to check that the inverter was >> incommunicado. this is a different computer (t43 like the xp box) >> with different fedora (16 vs 15). I wasn't around that day. > > You might look for differences between the two computers. For example, > the interfering program might be something like ModemManager or > usb_modeswitdh, installed on one machine but not the other. > >> ok. so now I need to redo on a day that I know I'm around to confirm >> that the inverter gets nobbled. I'll confirm that the tusb >> interference is happening, too. > > It's worth repeating that you don't have to do these tests overnight. > If you unplug the TUSB, enable usbfs_snoop, start up wireshark, and > then plug the TUSB back in -- all during the daytime -- that should be > good enough to spot whatever is going wrong. And it won't generate an > immense log file, either. > > 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
