[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1185578908.2989.15.camel@x2>
Date: Fri, 27 Jul 2007 18:28:28 -0500
From: Paul Fulghum <paulkf@...rogate.com>
To: Lee Howard <faxguy@...ardsilvan.com>
Cc: Tilman Schmidt <tilman@...p.cc>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Robert Hancock <hancockr@...w.ca>,
linux-serial@...r.kernel.org, tytso@....edu, rmk@....linux.org.uk,
linux-kernel@...r.kernel.org
Subject: Re: serial flow control appears broken
On Fri, 2007-07-27 at 13:48 -0700, Lee Howard wrote:
> Here's the output:
>
> type: 4
> line: 1
> line: 760
> irq: 3
> flags: 1358954688
> xmit_fifo_size: 16
> custom_divisor: 0
> baud_base: 115200
OK, the FIFO should be enabled.
What is known:
* The error is a hardware FIFO overrun.
- observed message is in n_tty due to driver setting TTY_OVERRUN
* The RTS/CTS flow control is not involved
- this is done only by the ldisc in response to buffer levels
- you verified crtscts is set
- you did not observed RTS change when 'overflow error' logged
- you did observe RTS change when application stopped reading
So this seems to be a latency issue reading the receive
FIFO in the ISR. The current rx FIFO trigger level
should be 8 bytes (UART_FCR_R_TRIG_10) which gives the
ISR 694usec to get the data at 115200bps.
IIRC, in 2.2.X kernels this defaulted to 4 bytes
(TRIG_01) which gave a little more time to service the interrupt.
How does the data rate affect the frequency of the overrun errors?
Does 57600bps make them go away?
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists