Re: serial port not working correctly (you better read it if you want PPP)

[Ian Duggan]

> So, sending "0123456789ABCDEF" will result in
> RECi => 0123456789ABCD
> CTIi => EF

[snip]

> Anybody has an idea how to proceed with this problem?  Has anybody gotten
> serial line communication to work reliably?  BTW, we have tested PPP and the
> tunnel device without using the serial connection (Neal set it up to send
> the packets over ethernet), and it works just fine.  So, after fixing the
> com device, we will have PPP working flawlessly. ;)

Most serial hardware that comes with modern computers makes use of a 16
byte buffer. The 14 byte symptoms you are seeing are mostly likely
coming from the high-water trigger setting for the serial hardware being
set to 14 bytes, a typical default.

It looks like this:

16 byte buffer which receives bytes off the wire. When the buffer
reaches the "high water mark" (14 bytes in this case), it triggers an
interrupt, RECi in this case, which I guess stands for RECEIVE.

The RECi interrupt should move the characters from the 16 byte buffer
and place it into a larger kernel buffer, using appropriate locking.

The CTIi interrupt you are seeing is a timeout interrupt. This is used
to cover the case where anough bytes aren't recieved to trigger the high
water interrupt. The serial hardware issues these at a regular interval
to keep the buffer clear.


Looking at what you have sent so far, my guess is that the RECi
interrupt is being triggered at 14 bytes and is only removing those 14
bytes from the buffer. My guess is that one or more bytes are recieved
into the buffer before RECi interrupt can be run and they are being left
there by the interrupt code. That is why they are showing up in the
resulting CTIi interrupt.

Make sure that RTIi is checking how many bytes to remove from the
buffer, and isn't just assuming the amount to remove. Also make sure
that the interrupts are using the appropriate locking and are leaving
the hardware in a consistent state when they exit. Maybe you aren't
releasing a lock or informing the hardware that you are done. (Not sure
how this would be done.)


Things to try:

1) Sending data 14 bytes at a time. (Isolate problem to RTI interrupt)
2) Sending data <14 bytes at a time. (Isolate problem to CTi itnerrupt)
3) Software Flow Control
4) Polling (Use of serial hardware without interrupts)


There is a lot of good info in the SERIAL Howto.

        http://www.ibiblio.org/mdw/HOWTO/Serial-HOWTO.html


--Ian










-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan                    ian@ianduggan.net
                              http://www.ianduggan.net