UART overrun errors
Mats Byggmastar
I'm working with some serial port code and (again) run into problems.
I open a port (/dev/ttyS0) at 115200 bps. Data is sent/received over
the port at a steady 64 kbit/s. I've also tried using lower speeds.
However, the port don't seem to be very reliable. As soon as there is
some disk activity, I immediately receive errors in my data stream.
Either bytes are lost or random bytes are inserted into the received data
stream. Checking in /proc/tty/driver/serial I see that a 16550A UART is
used. I can also see that the errors are registered as overrrun errors.
Does this mean that the interrupt that the 16550A issues isn't served by
the driver in time and the FIFO gets overwritten?
To eliminate the possibility that I could be picking up external noise
on the null-modem cable I tested the port in loopback, TX pin connected
to RX pin, with a very short wire. The problem was still there.
Anyone has some ideas what is going on?
I am using Red Hat 6.1
Mats
-------------------------------------------
Mats Byggmastar, B.Sc., SW Design Engineer
GSM/GPRS/D-AMPS cellular data testequipment
Moesarc Technology AS, Oslo Norway
ma...@moesarc.NOJUNK.no, tel: (+47)22516974
Tony R. Bennett
First let me preface this with "I'M NOT AN EXPERT"
A couple of things:
- the UART generates an interrupt when data is ready...
(Possibly, when there are certain number of bytes in
its FIFO buffer)...the OS prioritizes the interrupts
so a DISK interrupt may have priority over a serial port
interrupt... but we can't control that...
- An overrun error usually means:
- bytes not being pulled out fast enough...
...i.e. the system is VERY BUSY
or
- peer on the serial port is not obeying flow control
(RTS/CTS...or XON/XOFF)
HTH,
Tony
--
Anti-spam filter: I am not root@localhost
trb@teleport dot com COM Public Access User --- Not affiliated with Teleport
Johan Kullstam
oh yes we can. irqtune.
--
johan kullstam l72t00052
Mats Byggmastar
> > >
> > >Does this mean that the interrupt that the 16550A issues isn't served by
> > >the driver in time and the FIFO gets overwritten?
> > >
> >
> > - the UART generates an interrupt when data is ready...
> > (Possibly, when there are certain number of bytes in
> > its FIFO buffer)...the OS prioritizes the interrupts
> > so a DISK interrupt may have priority over a serial port
> > interrupt... but we can't control that...
>
> oh yes we can. irqtune.
irqtune ?
Is that some kernel internal stuff or can it be accessed from
user space?
The funny thing with my problem is that I once was on a seminar
with Linus himself where he talked about (among other things) how
Linux can receive "hi-speed" serial data without problem as the
kernel was built in a smart way...
Well, now my system (Pentium III) runs 98% idle and can't receive
64 kbit/s over a serial port.
Mats
Etienne Lorrain
>
> Johan Kullstam wrote:
> > >
> > > - the UART generates an interrupt when data is ready...
> > > (Possibly, when there are certain number of bytes in
> > > its FIFO buffer)...the OS prioritizes the interrupts
> > > so a DISK interrupt may have priority over a serial port
> > > interrupt... but we can't control that...
> >
> > oh yes we can. irqtune.
>
> irqtune ?
At the hardware level, the interrupt priority is:
0 1 8 9 10 11 12 13 14 15 3 4 5 6 7 (least priority)
You cannot change that on a PC.
> The funny thing with my problem is that I once was on a seminar
> with Linus himself where he talked about (among other things) how
> Linux can receive "hi-speed" serial data without problem as the
> kernel was built in a smart way...
> Well, now my system (Pentium III) runs 98% idle and can't receive
> 64 kbit/s over a serial port.
>
> Mats
Yes, sure. But there is a bug in some IDE hardware drivers, you
have to disable interrupts when tranfering bytes to/from Hard Drives
else you get physical corruption of data. So by default, the IDE
driver disable interrupts quite a long time. This problem was
just on very few PCs, and a long time ago, but was not detectable
so by default, Linux configuration disable interrupts.
In short, use "hdparm" to enable interrupts when tranfering data
to/from HD, in your rc scripts.
Etienne.
Josef Moellers
>
> Mats Byggmastar wrote:
> >
> > Johan Kullstam wrote:
> > > >
> > > > - the UART generates an interrupt when data is ready...
> > > > (Possibly, when there are certain number of bytes in
> > > > its FIFO buffer)...the OS prioritizes the interrupts
> > > > so a DISK interrupt may have priority over a serial port
> > > > interrupt... but we can't control that...
> > >
> > > oh yes we can. irqtune.
> >
> > irqtune ?
>
> At the hardware level, the interrupt priority is:
> You cannot change that on a PC.
This is not quite right.
If you take the list you give, you can split it into two and exchange
the two parts.
The 8259 has several "End-Of-Interrupt Operation" modes, two of wich
are:
- Automatic Rotation, where the last interrupt serviced will
automatically get the least priority and
- Specific Rotation, where you can specify which interrupt will get the
least priority.
E.g. when you start with your sequence and you get an interrupt on IRQ
12, when using Automatic Rotation, you end up with
0 1 13 14 15 8 9 10 11 12 3 4 5 6 7
The specific relative priority comes from the fact that there are two
8-channel interrupt controllers that are cascaded: the second one is
hooked to IRQ2 if the first one.
--
Josef Möllers
Fujitsu Siemens Computers
SHV Server DS 1
Johan Kullstam
> Johan Kullstam wrote:
> > > >
> > > >Does this mean that the interrupt that the 16550A issues isn't served by
> > > >the driver in time and the FIFO gets overwritten?
> > > >
> > > A couple of things:
> > >
> > > - the UART generates an interrupt when data is ready...
> > > (Possibly, when there are certain number of bytes in
> > > its FIFO buffer)...the OS prioritizes the interrupts
> > > so a DISK interrupt may have priority over a serial port
> > > interrupt... but we can't control that...
> >
> > oh yes we can. irqtune.
>
> irqtune ?
>
> Is that some kernel internal stuff or can it be accessed from
> user space?
it's both. irqtune is actually a kernel module with a wrapper. you
run it in userspace (as root of course) and the script inserts the
irqtune module which then rearranges interrupt priorities. then the
module is removed but the priorities remain. please see the irqtune
website. it's quite informative.
<URL:http://www.best.com/~cae/irqtune/>
--
johan kullstam l72t00052
Mats Byggmastar
> In short, use "hdparm" to enable interrupts when tranfering data
> to/from HD, in your rc scripts.
Thanks!
From the hdparm man page:
-u Get/set interrupt-unmask flag for the drive. A setting of 1
permits the driver to unmask other interrupts during
processing of a disk interrupt, which greatly improves Linux's
responsiveness and eliminates "serial port overrun" errors.
:-)
I tested it and it seems to work fine. Running updatedb and firing
up netscape at the same time did not interfere with my serial traffic.
Only when switching from X Windows to console mode (CTRL-ALT-F*) I got
some overrun errors. I guess this is the same problem but it is not
as critical for my application.
Mats
Etienne Lorrain
> Etienne Lorrain wrote:
> > In short, use "hdparm" to enable interrupts when tranfering data
> > to/from HD, in your rc scripts.
>
> some overrun errors. I guess this is the same problem but it is not
> as critical for my application.
You may have the same problem (serial overruns) when using any
function which switch back to real mode and calls the BIOS - I do not
know if the BIOS is called while switching console.
The problem is that BIOS manufacturers (standart BIOS, video BIOS,
SCSI BIOS...) do not want the user to view their assembly code, with
a debugger or another way - so they make (nearly) impossible to trace
or single step their code. I suspect they are not only disabling
interrupts but also relocate the interrupt table (l/sidt assembly
instruction) and put the stack in an un-useable state, like pointing
in ROM. Their BIOS is not necessarily optimised (it maybe the first
reason they do not want us to see it) so it takes quite a long time
with interrupts disabled...
Hope that helps,
Etienne.
Mats Byggmastar
>
> You may have the same problem (serial overruns) when using any
> function which switch back to real mode and calls the BIOS - I do not
> know if the BIOS is called while switching console.
>
> The problem is that BIOS manufacturers (standart BIOS, video BIOS,
> SCSI BIOS...) do not want the user to view their assembly code, with
> a debugger or another way - so they make (nearly) impossible to trace
> or single step their code. I suspect they are not only disabling
> interrupts but also relocate the interrupt table (l/sidt assembly
> instruction) and put the stack in an un-useable state, like pointing
> in ROM. Their BIOS is not necessarily optimised (it maybe the first
> reason they do not want us to see it) so it takes quite a long time
> with interrupts disabled...
>
> Hope that helps,
Yes, it helps. It helps in the way that I'm becomming more and more
convinced that Linux is not the correct OS for our application.
The realtime issues with Linux I've been avare of for a long time
but it hasn't had any major impact on our product although it is
a realtime type of application (a GSM protocol analyser/simulator
for the A and Abis interfaces, E1, 2 Mbit/s). We have managed to
work around the problems. However, with these serial port problems
I've had lately I'm becomming very skeptic. We simply have to move
over to a RTOS.
Mats
Villy Kruse
Etienne Lorrain <etienne...@yahoo.fr> wrote:
>
> The problem is that BIOS manufacturers (standart BIOS, video BIOS,
> SCSI BIOS...) do not want the user to view their assembly code, with
> a debugger or another way - so they make (nearly) impossible to trace
> or single step their code. I suspect they are not only disabling
> interrupts but also relocate the interrupt table (l/sidt assembly
> instruction) and put the stack in an un-useable state, like pointing
> in ROM. Their BIOS is not necessarily optimised (it maybe the first
> reason they do not want us to see it) so it takes quite a long time
> with interrupts disabled...
>
But that is not relevant for linux as it does not use BIOS for any
device access anyway. The linux code is open so you can actualy see
for yourself. There is a function in BIOS that is used, however, and
that is accessing the PCI configuration information, and possible also
the sleep and power management functionality.
Villy
Villy Kruse
Mats Byggmastar <ma...@moesarc.NOJUNK.no> wrote:
>Hello,
>
>I'm working with some serial port code and (again) run into problems.
>I open a port (/dev/ttyS0) at 115200 bps. Data is sent/received over
>the port at a steady 64 kbit/s. I've also tried using lower speeds.
>However, the port don't seem to be very reliable. As soon as there is
>some disk activity, I immediately receive errors in my data stream.
>Either bytes are lost or random bytes are inserted into the received data
>stream. Checking in /proc/tty/driver/serial I see that a 16550A UART is
>used. I can also see that the errors are registered as overrrun errors.
>
>Does this mean that the interrupt that the 16550A issues isn't served by
>the driver in time and the FIFO gets overwritten?
>
>To eliminate the possibility that I could be picking up external noise
>on the null-modem cable I tested the port in loopback, TX pin connected
>to RX pin, with a very short wire. The problem was still there.
>
>Anyone has some ideas what is going on?
>
It is possible that the IRQ is misconfigured for the port in question,
but in that case you shouldn't expect anything to work properly. It is
said that you can use a 16550 port without interrupt support at normal
typing speed, that is not more than 100 bits per second.
I once tried to make a ppp connection at 345600 bps on a 50Mhz 486,
and it worked properly. There were in this case no modem to slow the
efective data rate down to 50 or 60 kbps. You do need to make sure that
the user level program can take the data at that speed or something is
lost somewhere.
The 345600 bps should generate an interupt once every 16 bytes or
approximately 2 every milisecond. A 64kbs data stream should generate 400
interupts for each second. The timer tick normaly produces 100 interupts
each second. That should be within the ability of most systems.
Disk interrupts would only occure once per full disk block written, and if
you use a SCSI disk controller with DMA or bus masterning the influence
from the disk system should be minimal. IDE disk using programed io
woule put more load on the CPU, but these days you can get IDE systems
that can do DMA as well.
Villy
Kaz Kylheku
wrote:
>Hello,
>
>I'm working with some serial port code and (again) run into problems.
>I open a port (/dev/ttyS0) at 115200 bps. Data is sent/received over
>the port at a steady 64 kbit/s. I've also tried using lower speeds.
>However, the port don't seem to be very reliable. As soon as there is
>some disk activity, I immediately receive errors in my data stream.
>Either bytes are lost or random bytes are inserted into the received data
>stream. Checking in /proc/tty/driver/serial I see that a 16550A UART is
>used. I can also see that the errors are registered as overrrun errors.
The 16550A UART only buys you the ability to transfer several bytes at a time
rather than using one interrupt for each bytes.
Ultimately, you still need to use hardware flow control. Are you doing that?
>Does this mean that the interrupt that the 16550A issues isn't served by
>the driver in time and the FIFO gets overwritten?
If you can't use flow control, real time response is needed to not miss the
arrival data. Linux is not a real time OS.
Mika
System is based on Red-Hat 6.0, kernel 2.2.10 with RTAI 0.7. I am switched
off the default /dev/ttyS1 driver and using the rt_com package. I use
my own kernel module to read the rt_com's internal buffers and the user
space process takes the data via FIFO or SHMEM. Just today I downloaded the
60MB file to my disk while I was playing the game in the another process...
BUT, I have not checked the real speed yet... but it seems like it is 115k
Well that is the situation just now, but dunno whats coming on when
the whole application is ready ;)
Anyway if you are going to need realtime responses and other realtime
stuff
it is worth to look more closely the rtai ... or rtl extensions at
http://www.rtai.org
Hope this gives any helps for you.
Mika Lauronen
Mats Byggmastar wrote:
Etienne Lorrain wrote:
>
> You may have the same problem (serial overruns) when using any
> function which switch back to real mode and calls the BIOS - I do not
> know if the BIOS is called while switching console.
>
> The problem is that BIOS manufacturers (standart BIOS, video BIOS,
> SCSI BIOS...) do not want the user to view their assembly code, with
> a debugger or another way - so they make (nearly) impossible to trace
> or single step their code. I suspect they are not only disabling
> interrupts but also relocate the interrupt table (l/sidt assembly
> instruction) and put the stack in an un-useable state, like pointing
> in ROM. Their BIOS is not necessarily optimised (it maybe the first
> reason they do not want us to see it) so it takes quite a long time
> with interrupts disabled...
>
> Hope that helps,Yes, it helps. It helps in the way that I'm becomming more and more
convinced that Linux is not the correct OS for our application.
The realtime issues with Linux I've been avare of for a long time
but it hasn't had any major impact on our product although it is
a realtime type of application (a GSM protocol analyser/simulator
for the A and Abis interfaces, E1, 2 Mbit/s). We have managed to
work around the problems. However, with these serial port problems
I've had lately I'm becomming very skeptic. We simply have to move
over to a RTOS.Mats
-- Mastersoft Oy Kyllikinkatu 3 SF-80260 Joensuu Finland tel.+358-40-556 0728 fax.+358-13-223 613 mailto: laur...@mastersoft.fi
Mats Byggmastar
> The 16550A UART only buys you the ability to transfer several bytes at a time
> rather than using one interrupt for each bytes.
>
> Ultimately, you still need to use hardware flow control. Are you doing that?
Yes, same problem as with no flow control. Is RTS/CTS flow control actually
controlled by the UART itself? If it was, I would not have these problems.
Mats
Anders Larsen
The 16550C UART can do RTS/CTS flow control in hardware (16550A/B not).
I don't know if the driver makes use of this feature, though.
--
Anders Larsen
Etienne Lorrain
> Yes, it helps. It helps in the way that I'm becomming more and more
> convinced that Linux is not the correct OS for our application.
> The realtime issues with Linux I've been avare of for a long time
> but it hasn't had any major impact on our product although it is
> a realtime type of application (a GSM protocol analyser/simulator
> for the A and Abis interfaces, E1, 2 Mbit/s).
Linux is not a RTOS. It can handle some real time tasks, mostly
when correctly configured (HZ, good hardware so only good drivers
linked in the kernel) - but if you want 100 % get the next 4.75 ms
frame - you need external hardware.
A RTOS is not managing virtual memory because a page fault
may produce a delay of tens of ms... A RTOS may crash within
few ms if overloaded, so it is only tested on one or two
configuration, not on all the PCs whatever the RAM/processor.
> We have managed to
> work around the problems. However, with these serial port problems
> I've had lately I'm becomming very skeptic. We simply have to move
> over to a RTOS.
You probably need to change the hardware also, the 80x86 is not made
for hard real time kernels (hardware time to treat an IRQ, slow access
to I/O space), and whatever kernel you choose, if it access BIOS,
will disable interrupts for a lot too long. Linux is nearly never
using BIOS - but for some strange hardware: look what you have
on your board... Do not forget also to disable power management
system while you are getting frames.
My € 0.02
Etienne.
Etienne Lorrain
> The 16550C UART can do RTS/CTS flow control in hardware (16550A/B not).
> I don't know if the driver makes use of this feature, though.
It does make use of it. Also check for 16650 and 16750 and others
(bigger FIFO) - and PCI boards to not have the ISA delays -
see file "serial.c"
Mats Byggmastar
> It does make use of it. Also check for 16650 and 16750 and others
> (bigger FIFO) - and PCI boards to not have the ISA delays -
> see file "serial.c"
I think I've found a possible solution. A manufacturer of some
modem test equipment recommend RocketPort multi-port serial cards
from Comtrol for being very reliable. These boards are supported
under Linux and uses UART's with 1024 byte rx and 256 byte tx FIFO's.
This would give more than one second buffering on rx at 64 kbit/s.
I'm very thankful for all the help and hints all of you here on this
newsgroup have given me.
Mats
Mats Byggmastar
> This would give more than one second buffering on rx at 64 kbit/s.
Uhm.. make that over 100 ms buffering.
Mats