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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070727125655.6a71ab77@the-village.bc.nu>
Date:	Fri, 27 Jul 2007 12:56:55 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Lee Howard <faxguy@...ardsilvan.com>
Cc:	Uwe Kleine-König 
	<ukleinek@...ormatik.uni-freiburg.de>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: serial flow control appears broken

> -parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts

Ok so crtscts is set, but you have clocal set too. That shouldn't matter

> Using software flow control this is what stty tells me about the port 
> set up done by the application:

This also looks fine

> They seem correct to me, but I am certainly willing to be wrong.

clocal set as well is unusual but if I remember the spec right then
clocal would not interfere with rts/cts handshake and certainly not with
xon/xoff

Looks correct, two boards so its unlikely both didnt wire it.

> A quick google on "input overrun(s)" may lend some credence (although, 
> certainly this is not in any way conclusive) that I'm not the only one 
> who may be seeking a solution on this matter.
> 
>   http://www.google.com/search?hl=en&q=%2B%22input+overrun%28s%29%22

Those look different on the whole - there are two reasons you'll get an
input overrun with a 16x50 UART. The first is because we ran out of
buffers to empty the chip, in which case we would have asserted flow
control in software. The second is if we cannot keep up and fail to empty
the on chip FIFO within the required time (about 1mS)

As the flow control is driven by software on most 16x50 chips (there are
a couple of exceptions) if we fail to empty the fifo fast enough then any
flow control will be asserted too late to save the day.

If you stop the application and do the following

	cat /dev/ttywhatever
	^Z
	[stopped]

(so you are asking the OS to buffer data but not ever reading it)

and then fire data at it does the flow control eventually occur ?

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