problems with serial driver

problems with serial driver

[slack]

Hi!
I've got some problems with serial communication.
So, connecting 2 serial ports via the cable (tested on several fast
computers with
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A)
No IRQ conflicts (pure computers without additional boards).
1. Starting receiver, sender: all is OK.
2. Starting sender, receiver: sometimes OK, sometimes I've got damaged
data. Sometimes - IRQ overruns (losting NULL pointer etc). Kernel down.

Progs are very simple: send/receive (like in HOWTO). So,
operations are intensive. Installation of some
usleeps before read() from port solves the problem.
Kernels are up to 2.4.18 and on modern up to 2.5.17.
(newer are not tested).

Re: problems with serial driver

[Stuart MacDonald]

From: <slack@slackware.ru>
> 1. Starting receiver, sender: all is OK.
> 2. Starting sender, receiver: sometimes OK, sometimes I've got damaged
> data. Sometimes - IRQ overruns (losting NULL pointer etc). Kernel down.

I'm not convinced this is a problem. The sender starts sending data
right away, correct? Well, that data is discarded by the receiver port
since it's not open for reading. The port knows it's not opened, and
thus nobody is interested in the data coming in, so it drops it. This
is correct behaviour.

> Progs are very simple: send/receive (like in HOWTO). So,
> operations are intensive. Installation of some
> usleeps before read() from port solves the problem.
> Kernels are up to 2.4.18 and on modern up to 2.5.17.

Installation of usleep()s where? In the user space application? That
shouldn't make a difference. Actually it should make it worse.

..Stu

Re: problems with serial driver

[slack]

On Tue, 3 Sep 2002, Stuart MacDonald wrote:

> From: <slack@slackware.ru>
> > 1. Starting receiver, sender: all is OK.
> > 2. Starting sender, receiver: sometimes OK, sometimes I've got damaged
> > data. Sometimes - IRQ overruns (losting NULL pointer etc). Kernel down.
> I'm not convinced this is a problem. The sender starts sending data
> right away, correct? Well, that data is discarded by the receiver port
> since it's not open for reading. The port knows it's not opened, and
> thus nobody is interested in the data coming in, so it drops it. This
> is correct behaviour.
It is clear. Not so clear, why it produces garbage when read from port, as
if it cannot sync with line.

> > Progs are very simple: send/receive (like in HOWTO). So,
> > operations are intensive. Installation of some
> > usleeps before read() from port solves the problem.
> > Kernels are up to 2.4.18 and on modern up to 2.5.17.
> Installation of usleep()s where? In the user space application? That
> shouldn't make a difference. Actually it should make it worse.
in the simple prog, that is doing read() from the port (intensive read).

for()
usleep();
read();
}
read OK.

for() {
// usleep()
read();
}
Garbage.

Re: problems with serial driver

[Stuart MacDonald]

From: <slack@slackware.ru>
> It is clear. Not so clear, why it produces garbage when read from port, as
> if it cannot sync with line.

It can't sync with the line. Serial transmission doesn't include a
specific syncing marker.

Yes, I know about the start bit. However, when a uart starts looking
at a line that already has data on it, how does it know which one is
the start bit? It takes the first thing that looks like a start bit,
which could be a bit in the middle of a character, and thus get
mis-synced. This is the way serial transmission works.

If you try replugging the cable while the sender and receiver are
running, you will notice that occasionally you'll get lucky and get a
correct sync, but often you'll get a mis-sync and receive garbage.

> for()
> usleep();
> read();
> }
> read OK.
>
> for() {
> // usleep()
> read();
> }
> Garbage.

This shouldn't make a difference, but I suspect that the usleep() is
luckily making the timing work out so that you get a correct sync
instead of a mis-sync.

However, if you've started the sender first, in the time it takes you
to start the receiver, the uart is dropping data. Even when you don't
get garbage you should notice that you're missing the first few bytes.

..Stu

--
We make multiport serial boards.
<http://www.connecttech.com>
(800) 426-8979

Re: problems with serial driver

[slack]

On Tue, 3 Sep 2002, Stuart MacDonald wrote:

> From: <slack@slackware.ru>
> > It is clear. Not so clear, why it produces garbage when read from port, as
> > if it cannot sync with line.
> It can't sync with the line. Serial transmission doesn't include a
> specific syncing marker.
I see. :)
> Yes, I know about the start bit. However, when a uart starts looking
> at a line that already has data on it, how does it know which one is
> the start bit?
yes, we cannot detect that.

> If you try replugging the cable while the sender and receiver are
> running, you will notice that occasionally you'll get lucky and get a
> correct sync, but often you'll get a mis-sync and receive garbage.
Everything is clear, not a problem. The problem is with overruns.
I have no idea on how to debug such events. And I cannot detect, what is
OK and what is not OK (maybe, problems with interrupt, or, port cannot
detect the start bit etc.), When I put some code between the read()s, it
brings delays, everything works, more, can sync without any problem with
start bit (mystic, I see, but... cannot debug). Also, cannot catch the
overrun.

> However, if you've started the sender first, in the time it takes you
> to start the receiver, the uart is dropping data. Even when you don't
> get garbage you should notice that you're missing the first few bytes.
it is not a problem, if only few. but I've got a stable garbage (frequency
is higher, than of normal data - the fact put me in a strange state;
statistics must say 50/50, but real life 90/10...) or stable normal data.

and, also, overruns. is it normal, when we like to read data from the port
with frequency, that is higher, than bus freq.? I think, no. is it
possible to eliminate such problems? it is hard to control such behaviour
of the system, it becomes unstable. ordinary user can put such calculator
in off state. :)

Re: problems with serial driver

[Stuart MacDonald]

From: <slack@slackware.ru>
> Everything is clear, not a problem. The problem is with overruns.
> I have no idea on how to debug such events. And I cannot detect, what is
> OK and what is not OK (maybe, problems with interrupt, or, port cannot
> detect the start bit etc.), When I put some code between the read()s, it
> brings delays, everything works, more, can sync without any problem with
> start bit (mystic, I see, but... cannot debug). Also, cannot catch the
> overrun.

I don't understand you.

When the receiver port isn't open, but is receiving data, the uart has
the rx circuits turned off. There will be no overruns, because the
hardware is ignoring the input line. When the port is open, but reads
aren't happening fast enough, the driver discards the extra data
silently. Overruns usually indicate a hardware problem.

> it is not a problem, if only few. but I've got a stable garbage (frequency
> is higher, than of normal data - the fact put me in a strange state;
> statistics must say 50/50, but real life 90/10...) or stable normal data.

If you attach to an existing serial data stream, you should get a
mis-sync most of the time. Assuming 8N1 you have a start bit, 8 bits
of character and a stop bit. 10 bits total. Only one is correct, the
start bit, so your random sync attempt should work 1 in 10 times. It
will actually work a little higher, as some of the character bits
don't look like the stop bit and get skipped over, but 90/10 isn't an
unreasonable result.

> and, also, overruns. is it normal, when we like to read data from the port
> with frequency, that is higher, than bus freq.? I think, no. is it
> possible to eliminate such problems? it is hard to control such behaviour
> of the system, it becomes unstable. ordinary user can put such calculator
> in off state. :)

The bus frequency (PCI bus, ISA bus etc) should be mostly irrelevant.
You'd only care if you had a serial port expansion card that was
clocked at a very high base baud rate, and it was an ISA card.

..Stu

--
We make multiport serial boards.
<http://www.connecttech.com>
(800) 426-8979

Re: problems with serial driver

[slack]

On Tue, 3 Sep 2002, Stuart MacDonald wrote:

> > brings delays, everything works, more, can sync without any problem with
> > start bit (mystic, I see, but... cannot debug). Also, cannot catch the
> > overrun.
> I don't understand you.
> When the receiver port isn't open, but is receiving data, the uart has
> the rx circuits turned off. There will be no overruns, because the
> hardware is ignoring the input line. When the port is open, but reads
> aren't happening fast enough, the driver discards the extra data
> silently. Overruns usually indicate a hardware problem.
Hm... Hardware problem on different chipsets, different processors,
different kernels(only chip is 16550A). I understand, that this can
indicate hardware problems.
But..

> of character and a stop bit. 10 bits total. Only one is correct, the
> start bit, so your random sync attempt should work 1 in 10 times. It
> will actually work a little higher, as some of the character bits
> don't look like the stop bit and get skipped over, but 90/10 isn't an
> unreasonable result.
OK, I know that. It is clear. Can You tell me, why usleep(100) totally
eliminates the problem with garbage?

> The bus frequency (PCI bus, ISA bus etc) should be mostly irrelevant.
> You'd only care if you had a serial port expansion card that was
> clocked at a very high base baud rate, and it was an ISA card.
:) Ok, Ok. Have You ever got in touch with 2xP4 Xeon Mother with ISA slots
from Supermicro? The problem is in fact, that I ve get total kernel halts
when often open/close/startprog with serial ports. For example, running
script, that launches the prog and killing it, can kill the comp in a
short period of time with overruns.
Sorry, I'm short in deep HW knowledge, and, also, I have no much time
to debug such problem(but like to do that). :( Also, I don't know, how to
debug it in a better way in the kernel.

Re: problems with serial driver

[Stuart MacDonald]

From: <slack@slackware.ru>
> Hm... Hardware problem on different chipsets, different processors,
> different kernels(only chip is 16550A). I understand, that this can
> indicate hardware problems.

That certainly indicates a driver problem. Interesting.

> OK, I know that. It is clear. Can You tell me, why usleep(100) totally
> eliminates the problem with garbage?

No idea, except that you're getting lucky. Always start the receiver
first.

> :) Ok, Ok. Have You ever got in touch with 2xP4 Xeon Mother with ISA slots
> from Supermicro? The problem is in fact, that I ve get total kernel halts
> when often open/close/startprog with serial ports. For example, running
> script, that launches the prog and killing it, can kill the comp in a
> short period of time with overruns.

Double check that you don't have any irq conflicts. An overrun can
happen when the driver's handler is delayed too long. It used to be
that the IDE interrupt handler was very long, and that would delay
other handlers, including the serial driver's. Also, double check that
the resources (irq, memory, etc) you're using for the ISA slots is
reserved by the bios so that the PCI system doesn't also use it.

Hm, actually, I've assumed that you have serial ports on an ISA card.
If you're having problems with the on-board serial ports on your
motherboard, you'll need to contact the serial driver maintainer (Ted
T'so, although he hasn't done much with it recently), or perhaps
Russell King (likely the next serial maintainer). I'm just a serial
driver hacker. :-)

> Sorry, I'm short in deep HW knowledge, and, also, I have no much time
> to debug such problem(but like to do that). :( Also, I don't know, how to
> debug it in a better way in the kernel.

I don't have any quick n easy tips on how to determine if the
interrupt routine is being delayed. There is a low latency patch (or
possibly config option) that speeds up the handling of bytes in the
serial/tty drivers; you could try that and see if it helps.

..Stu

Re: problems with serial driver

[slack]

On Wed, 4 Sep 2002, Stuart MacDonald wrote:

> From: <slack@slackware.ru>
> > Hm... Hardware problem on different chipsets, different processors,
> > different kernels(only chip is 16550A). I understand, that this can
> > indicate hardware problems.
> That certainly indicates a driver problem. Interesting.

> > OK, I know that. It is clear. Can You tell me, why usleep(100) totally
> > eliminates the problem with garbage?
> No idea, except that you're getting lucky. Always start the receiver
> first.
:) Starting sender, starting receiver, CtrlC (kill -15, getting KILL
signal in the prog). One note: both ports are on the same comp.

> > when often open/close/startprog with serial ports. For example, running
> > script, that launches the prog and killing it, can kill the comp in a
> > short period of time with overruns.
> Double check that you don't have any irq conflicts.
Quatro check. I do not know how, but serverworks defines IRQs after 16 for
side devices. But I have pure computers, without any devices. Of cource,
I've got bad results on well-weaponed comp (audio, video IO etc.).
With another chipset (860). Then, checkin new computers, that are virgin.

> An overrun can
> happen when the driver's handler is delayed too long.
I see this, in the driver. But do not know what to do.

> It used to be
> that the IDE interrupt handler was very long, and that would delay
> other handlers, including the serial driver's.
Ah! Those old discussion about slow(long) and fast(short) interrupts?

> Also, double check that
> the resources (irq, memory, etc) you're using for the ISA slots is
> reserved by the bios so that the PCI system doesn't also use it.
Hm... Where riside COM on-board ports? On which BUS (PCI/ISA)?

> Hm, actually, I've assumed that you have serial ports on an ISA card.
> T'so, although he hasn't done much with it recently), or perhaps
> Russell King (likely the next serial maintainer). I'm just a serial
> driver hacker. :-)
:-)
OK.

> interrupt routine is being delayed. There is a low latency patch (or
> possibly config option) that speeds up the handling of bytes in the
> serial/tty drivers; you could try that and see if it helps.
Thanx!

Re: problems with serial driver

[Stuart MacDonald]

From: <slack@slackware.ru>
> :) Starting sender, starting receiver, CtrlC (kill -15, getting KILL
> signal in the prog). One note: both ports are on the same comp.

Always start the receiver first. Otherwise it's not guaranteed that
the serial receiver will sync properly with the data stream.

> Quatro check. I do not know how, but serverworks defines IRQs after 16 for
> side devices. But I have pure computers, without any devices. Of cource,
> I've got bad results on well-weaponed comp (audio, video IO etc.).
> With another chipset (860). Then, checkin new computers, that are virgin.

Irq conflicts can and do happen with on-board devices. Or are you
really running a no-video, no-nic, no-sound, no-parallel-port,
no-keyboard, no-mouse serial-console-only machine?

> > happen when the driver's handler is delayed too long.
> I see this, in the driver. But do not know what to do.

You see that the handler (in a live running machine) is delayed? You
have more "deep hardware knowledge" than you think. :-)

> Ah! Those old discussion about slow(long) and fast(short) interrupts?

An interrupt handler runs when interrupts are off. That means no other
hardware can have their interrupts acknowledged and handled. So if the
IDE subsystem has a very long (long running time) handler, the uarts
generate "fifo full" interrupts, but they are ignored for a long time.
In the meantime, the fifo fills and overruns.

I think the discussion you're thinking of is hardware interrupt
handlers vs software interrupt handlers (bottom halfs, but I think
they're going away, see tasklets).

> Hm... Where riside COM on-board ports? On which BUS (PCI/ISA)?

Don't know. Check with your manufacturer.

..Stu

Re: problems with serial driver

[David Lawyer]

On Tue, Sep 03, 2002 at 11:29:59AM -0400, Stuart MacDonald wrote:
> From: <slack@slackware.ru>
> > It is clear. Not so clear, why it produces garbage when read from port, as
> > if it cannot sync with line.
> 
> It can't sync with the line. Serial transmission doesn't include a
> specific syncing marker.
> 
> Yes, I know about the start bit. However, when a uart starts looking
> at a line that already has data on it, how does it know which one is
> the start bit? It takes the first thing that looks like a start bit,
> which could be a bit in the middle of a character, and thus get
> mis-synced. This is the way serial transmission works.
> 
> If you try replugging the cable while the sender and receiver are
> running, you will notice that occasionally you'll get lucky and get a
> correct sync, but often you'll get a mis-sync and receive garbage.
> 
> > for()
> > usleep();
> > read();
> > }
> > read OK.
> >
> > for() {
> > // usleep()
> > read();
> > }
> > Garbage.
> 
> This shouldn't make a difference, but I suspect that the usleep() is
> luckily making the timing work out so that you get a correct sync
> instead of a mis-sync.

Could it be that usleep() somehow triggers a flow control stop?  Then
when transmission resumes, it will start on a byte boundary and all will
be in sync.  One way for flow control to happen is for the serial buffer
in main memory to fill since it's not being read.  But then there would
still be a lot of garbage bytes stored in the buffer, followed by valid
bytes when the flow resumes.  So could these garbage bytes be flushed or
could usleep() somehow immediately cause a flow control stop without the
buffer filling?

I notice that the man page says usleep() is obsolete.

			David Lawyer

> 
> However, if you've started the sender first, in the time it takes you
> to start the receiver, the uart is dropping data. Even when you don't
> get garbage you should notice that you're missing the first few bytes.