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: <46AB631B.6070109@howardsilvan.com>
Date:	Sat, 28 Jul 2007 08:39:07 -0700
From:	Lee Howard <faxguy@...ardsilvan.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Paul Fulghum <paulkf@...rogate.com>,
	Tilman Schmidt <tilman@...p.cc>,
	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

Alan Cox wrote:

>>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.)
>>    
>>
>
>Can you send me a dmesg, there are some cases when high disk load can
>cause high interrupt latency in both 2.2 and 2.6 depending upon what is
>configured.
>

I've attached dmesg output.  The os version I used yesterday to run 
those tests was Debian 4.0r0 (kernel 2.6.18-4-686).  It's still running, 
and that's where I give you this dmesg output from.

> I don't think thats related to the main problem but it is
>worth knowing about hdparm -u1
>

# hdparm -u1 /dev/hda

/dev/hda:
 setting unmaskirq to 1 (on)
 unmaskirq    =  1 (on)
#

After doing this I re-ran the 5 test sends at 115200 bps.  The number of 
lost bytes were:  0, 14, 8, 0, and 3.  Compared with yesterday's 63, 5, 
44, 48, and 2 this may indicate an improvement.  Note also that in the 
4th session where no bytes were lost there was still one element of 
corrupt data as detected by the image decoder.

Thanks,

Lee.

View attachment "dmesg.out" of type "text/plain" (7309 bytes)