On Thu, 26 Jan 2012, Tim Coote wrote: > 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. There doesn't seem to be anything causing similar problems now. There's only the usual issue of the device not getting enough power until about 15 minutes after the Sun first comes up. > 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.) The worst error messages I see are a bunch of lines saying: Problem flushing before sending command: (5) Input/output error Problem draining command: (5) Input/output error around 11:19:00. This was not caused by a disconnection; instead the cause appears to have been noise in the USB signal. Whatever it was, it cleared up in less than 1/2 second and the device started working again. In the remainder of the wireshark trace, the device seemed to work well. > 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. That's right. > 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. There are a few lines saying "CRC receive error" or "No response". I get the feeling they are the result of bugs in the aurora program rather than problems in the device or the USB connection. Or maybe there's a bug in the ti_usb_3410_5052 driver, but that seems less likely. 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
