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: <46B202DE.5000709@shaw.ca>
Date:	Thu, 02 Aug 2007 10:14:22 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Mark Lord <lkml@....ca>
Cc:	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Russell King <rmk+lkml@....linux.org.uk>,
	Lee Howard <faxguy@...ardsilvan.com>,
	linux-serial@...r.kernel.org, tytso@....edu,
	linux-kernel@...r.kernel.org
Subject: Re: serial flow control appears broken

Mark Lord wrote:
> I don't believe the speed of the machine has much to do with it,
> as IDE PIO is always at pretty much the same speed (or slower)
> regardless of the CPU speed.
> 
> Best case is about .120 usec per 16-bit word, but that doesn't often pan 
> out
> in practice.  More typical is something closer to 1 usec per 16-bit word.
> 
> So, for multcount=16 (very common), best case is 16 * 256 * .120 = 491 
> usec,
> plus extra overhead for reading the IDE status register (another usec or 
> so),
> and other stuff.  Figure maybe 500usec total per interrupt for multcount=16
> in the best case, or 4000usec in the worst case.
> 
> At 115200bps, we get a byte every 86 usec or so.  Assuming the UART FIFO
> is set to interrupt (warn) us at 12/16 full, we have 4*86 = 344 usec to
> respond and de-assert RTS.  Less than that in practice.
> 
> Conclusion:  using IDE multisector PIO is not a good idea with high speed
> serial transfers happening, since we cannot respond quickly enough.
> 
> It might be possible to set the buffer underrun threshold lower in the 
> UART (?).
> 
> All that said, I doubt that his system is using IDE PIO in the first place.
> Dunno how long IDE DMA interrupts take, but it's probably in the 20-50 
> usec range.

I think that PIO transfers only have to be done with interrupts disabled 
on really old, evil controllers (without unmask set). I don't think 
libata ever disables interrupts during transfers(?)

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@...pamshaw.ca
Home Page: http://www.roberthancock.com/

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