Messages in this thread | | | Date | Tue, 5 Oct 1999 10:04:09 +0200 | From | Wojciech Zabolotny <> | Subject | Re: Bug in Linux serial driver (and fix proposal) |
| |
On Mon, Oct 04, 1999 at 03:46:00PM -0400, Theodore Y. Ts'o wrote: > Date: Mon, 4 Oct 1999 20:56:10 +0200 > From: Wojciech Zabolotny <wzab@ise.pw.edu.pl> > > I just discovered, that the user program can not detect the "overrun" > event in serial data (at least in 2.0.x kernels, I don't know the 2.2.x). > This is a serious bug in the serial driver, if it is used for applications > sensitive to data loss (eg. processing of data from AD converter connected > to the serial port). > > It's true that it would be nice if applications where informed about the > data loss, but most of the time there's not much they can do after the > fact, after data has been lost.
In my application (it is an "intelligent" A/D converter sending the data to the PC through RS at 115200) the detection of overrun is really essential. The user should be at least warned about such event, and if possible, the baudrate should be lowered (it can be done automatically by the application, and the break in the data stream may be marked in the recorded data).
The application shall be used in the hospitals, which due to permanent lack of money use very old hardware - so RS are offen 16450 based (no input FIFO), IDE controllers use only PIO mode and so on. I'm pretty sure, that there are more people who experience that problem.
I think that the first proposed solution (marking of overrun in the data stream, when PARMRK flag is set) does not increase seriously the size of driver's code, and should be safe for other applications (the sequence 0xff 0x01 has no meaning when PARMRK flag is used, so can be used for marking of overrun event).
> That's why currently the overrun case is treated as a system log; it's > an indication that system isn't setup correctly, or that there's a > kernel problem. In practice overruns should never happen. The most > common case of overruns is due to the IDE device driver taking too > long. Read the man page about hdparm's -u option, and try it. It > will likely cause your overrun problem to go away altogether. > > I'll think about adding your suggestions, but our time is almost > certain better spent trying to fix why the overrun's are happening in > the first place, rather than trying to improve ways that the application > is notified of the fact that something had gone wrong. Let's rather > concentrate on avoiding things from going wrong in the first place.
I agree, but Linux is often used on very old hardware (unusable with other contemporary OS's) and I have at least one computer, where there was no way to avoid overruns at 115200 (386/40MHz, 8MB RAM, IDE-PIO). The possibility of using such old hardware is one of big advatages of Linux (that's why most distributions still contain mainly binaries compiled for i386). The information about the overrun in the logfile may be easily overlooked... -- Thanks for all the answers Wojciech M. Zabolotny http://www.ise.pw.edu.pl/~wzab wzab@ise.pw.edu.pl
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |