linux-kernel - Re: serial flow control appears broken

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46AACB4D.7080004@howardsilvan.com>
Date:	Fri, 27 Jul 2007 21:51:25 -0700
From:	Lee Howard <faxguy@...ardsilvan.com>
To:	Paul Fulghum <paulkf@...rogate.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

Paul Fulghum wrote:

>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?
>  
>

The overrun error message does not occur on every instance of data 
corruption.  (I just became aware of this as I've not been paying so 
much attention to the error messages as I have been to the corrupt 
data.)  The data gets far more corrupted than the error messages would 
lead me to believe.  Since the data being sent from the fax modem to the 
host is identical (same image data) every time it's easier for me to 
measure the effect of one bitrate over another by examining the number 
of missing bytes from the data.

The image has a total of 140465 bytes.  Just now I sent it 5 times each 
at 115200, 57600, 38400, and 19200 bps.

At 115200 bps the number of bytes skipped were:  63, 5, 44, 48, and 2.

At 57600 bps the number of bytes skipped were:  0, 1, 13, 9, and 12.

At 38400 bps the number of bytes skipped were 858, 0, 0, 0, and 8.

At 19200 bps the number of bytes skipped were 0, 0, 0, 0, and 0.

Curiously, the session at 38400 bps that skipped 858 bytes... coincided, 
not just in sequence but also in precice timing within the session, with 
a small but noticeable disk load that I caused by grepping through a 
hundred session logs.  (I can't reproduce it easily, though, because of 
disk caching.)

And, perhaps this is relevant... the way that I have the fax modem 
sending the data to the host is by receiving it from another fax modem 
which is sending it.  Thus, the modem on ttyS0 is sending a fax to the 
modem on ttyS1.  Due to the error correction protocol that is performed 
between the two fax endpoints I can guarantee that the data is correct 
as it leaves the DCE.  I mention this in case there is any limitation to 
how the 8250 driver performs when two modems are being run simultaneously.

Thanks,

Lee.

-
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/