Serial problem and request for guidance..

Serial problem and request for guidance..

[Nameer Yarkon]

Hello,

Some of my serial rx data gets lost.

I can easily reproduce the problem on several kernel versions
and platforms (while I have several setups of different kernels
where this doesn't occur).
But I want to narrow it down a bit before filing a bug report.

In the meantime I would heartfully thank any guidance how I can
further debug this. Assuming I see the data on the lines
using a hardware sniffer, but then I do not receive it
on the host, any idea how I can debug this ?
Any hunch what it can be ? serial device misconfiguration ?

Thank you and sorry for such a vague report
and minimal info...
Nameer.

Re: Serial problem and request for guidance..

[Alan Cox]

> Some of my serial rx data gets lost.

Which hardware ?

> further debug this. Assuming I see the data on the lines
> using a hardware sniffer, but then I do not receive it
> on the host, any idea how I can debug this ?

If you are seeing most of it then I would imagine bytes are being lost
possibly due to latency. Are you trying to do very high speeds, is this a
USB device ?

> Any hunch what it can be ? serial device misconfiguration ?
> 
> Thank you and sorry for such a vague report
> and minimal info...

You need to be much more precise to get any useful recommendations

Re: Serial problem and request for guidance..

[Nameer Yarkon]

On Mon, Jun 16, 2008 at 3:03 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> Some of my serial rx data gets lost.
>
> Which hardware ?

It's a range of platforms/kernel versions and scenarios.
Currently it happens with a bluetooth device connected to standard UART
on ARM (OMAP) with an old 2.6.14 kernel, but only when I enable the
debug macros of the line discipline code (hci_h4, hci_ldisc,..).
When a big chunk of data arrives, more than
half of it is lost. even on 115200. But when I turn of the debug macros (BT_DBG
macros which are simply a bunch of prinks) the problem disappears. So I suspect
there are some nasty timing issues which lead to data loss.

I encountered similar problems last year even on a PC, with pre 2.6.21 kernels
(around 2.6.19 or even earlier IIRC) but it was all gone with 2.6.21 and 2.6.22.
Currently I have totally different machines, and these devices tend now to come
with USB-to-serial connectors so I'm not quite sure about up-to-date
kernels yet.

All I can say is that it is nasty and very hard to debug, and I'm not quite sure
how can I debug it as I find the serial/tty subsystems a bit perplexing.

I know this is not necessarily relevant to the tip of the kernel, and it still
lacks many details, but any guidance towards how can I debug it will
be much appreciated. If I will successfully reproduce it with a current
kernel I promise a full and detailed bug report.

Thank you for your time and patience !
Nameer.

Re: Serial problem and request for guidance..

[Alan Cox]

> on ARM (OMAP) with an old 2.6.14 kernel, but only when I enable the
> debug macros of the line discipline code (hci_h4, hci_ldisc,..).
> When a big chunk of data arrives, more than
> half of it is lost. even on 115200. But when I turn of the debug macros (BT_DBG

Not a suprise. The old buffering would struggle in this case.

> macros which are simply a bunch of prinks) the problem disappears. So I suspect
> there are some nasty timing issues which lead to data loss.
> 
> I encountered similar problems last year even on a PC, with pre 2.6.21 kernels
> (around 2.6.19 or even earlier IIRC) but it was all gone with 2.6.21 and 2.6.22.

We rewrote the tty buffering around the point it magically started
working so that would fit my suspicion.

Alan