| 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
| ||
|
Date: Fri, 29 Jul 2011 12:04:16 -0400 From: lsorense@...lub.uwaterloo.ca (Lennart Sorensen) To: linux-serial@...r.kernel.org Cc: Len Sorensen <lsorense@...lub.uwaterloo.ca>, linux-kernel@...r.kernel.org, Breno Leitao <leitao@...ux.vnet.ibm.com> Subject: Very strange data loss with jsm driver I discovered a strange situation where the jsm driver discards the majority of transmit data. I have two text files. The first file consists of 9100 lines of: 0123456789<newline> Total 100100 bytes. The second file consists of 100 lines of: 01234567890123456789.....0123456789<newline> (1000 character line) Total 100100 bytes. The first file transmits instantly, with the receiving end getting approximately 100 bytes of the data. The second file sends in about 1 minute and 40 seconds at 9600 baud (the speed doesn't affect the behaviour in any noticeable way) as one would expect, and the other end sees all the data. The trigger point appears to be lines of up to 14 bytes, followed by a newline. With 15 bytes or more per line it seems to be OK. Anyone got a clue? I was testing on 3.0.0. Same on 2.6.32. 3.0.0 unfortunately no longer has port statistics on the jsm driver in /proc/tty/driver/jsm making it hard to see what the driver believes is going on, it seems 2.6.37 broke that with some serial cleanup. I am cleaning up a patch to fix that. -- 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/
Powered by blists - more mailing lists