Re: Problems with USB-Serial adapter after upgrade to 2.6.26-1
On Sun, Aug 31, 2008 at 12:12:22PM +0200, u7l11ey@mail.lrz-muenchen.de wrote:
> On Sun, 31 Aug 2008, Greg KH wrote:
>
> > This should only be happening if the port is being closed and then data
> > is still in flight, right?
>
> I don't know what you mean by "port is being closed". I use the port for
> continuous logging of my solar heating system. The data are read into a
> file, and every 10 minutes, I re-init the reading process because in the
> past I frequently had some garbage in the data. This is the relevant part
> of my script:
>
> # Send command to heating controller to stop transmitting data:
> cat conende.dat > /dev/ttyUSB0
> sleep 2
The port is being opened and then closed right here with the call to
'cat'. That is what I was referring to.
And I would _really_ suggest not using cat for serial data through a
usb-serial device, over the years it has proven to just not work
properly. Use a "real" serial port program, like minicom or something
else.
> # Kill process reading the data from the serial port
> kill -15 `cat seriell_lesen.pid`
> sleep 2
>
> # Reset serial port
> stty sane < /dev/ttyUSB0
> stty raw < /dev/ttyUSB0
>
> # Rename data file for further processing later
> mv heizung.dat $IMPORT_DATEI
>
> # Start a new reading process
> nohup cat /dev/ttyUSB0 > ./heizung.dat &
> echo $! > seriell_lesen.pid
Hm, this cat session could still be running at the same time the one
above was, right? That's going to be a mess.
> # Send commands to the heating controller to start sending data
> cat conbeginn.dat > /dev/ttyUSB0
> sleep 2
> cat conauslesen.dat > /dev/ttyUSB0
>
>
> I do suspect that the "stty" commands are causing the problem, but I need
> to have the port in a defined state before using it. I will test without
> the stty commands and see what happens, but this can only be a workaround.
Can you try with a scripted minicom session instead?
> > If the driver is working properly, this should be safe to ignore, I
> > think the 2.6.27 kernel will have a lot of these types of warnings
> > resolved with all of the tty layer changes.
>
> No, the driver is NOT working properly. When the problem occurs, I have 10
> minutes without data! Sometimes, it occurs several times in a row, making
> the gaps in my data even longer.
Is this because one of the above steps fail?
It's not like the driver times out and then resets itself or anything
here.
thanks,
greg k-h
Reply to: