linux-kernel - Strange problem with tty layer

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-next>] [day] [month] [year] [list]

Message-ID: <20070124204009.GA7584@csclub.uwaterloo.ca>
Date:	Wed, 24 Jan 2007 15:40:09 -0500
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	linux-kernel@...r.kernel.org
Subject: Strange problem with tty layer

I am seeing a very strange problem which seems to be in the tty layer.

I am using an exar 17D154 based PCI card (like the digi neo style card)
using the jsm driver.  Kernel version 2.6.16.25.

My test involves connecting two ports together with a cross over cable
and then sending a test pattern of characters.  I am currently using
11520 characters at 230400bps (so 0.5s for the transfer).

Most of the time, it works perfectly, but once in a while, I never
receiver the last few characters (between 1 and 65 or so characters it
seems).

I have confirmed that the driver does in fact receive all the
characters, and that they are correct, and that they are being passed to
the tty layer using tty_insert_flip_string, and that it returns that all
the characters have been passed to the tty layer.  The user space
application however still doesn't see the last few characters (when it
fails).

The problem seems to occour every few hours of testing on a 266MHz Geode
SC1200.  When I change the clock to 133MHz, it happens every few minutes
instead (so much more frequently).  I suspect there is some race
condition that allows the tty layer to not get around to processing all
the data in the buffer, even when asked for data by the application
(which is waiting on the serial port using select, with a 4s timeout).

Any suggestions on where to head next to debug this?

Sending a few more characters when the receive times out before getting
the complete message does not cause the missing data to arive it seems,
only completely closing and starting the test program again seems to
recover it, although I may just not have been patient enough.

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