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 # 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 # 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. > 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. Regards, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
