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]

Date:	Thu, 02 Aug 2007 12:29:22 -0400
From:	Mark Lord <lkml@....ca>
To:	Robert Hancock <hancockr@...w.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

Robert Hancock wrote:
> 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(?)

That's what "hdparm -u1" (or -u0) controls.

But it doesn't matter a whit here.  The problem is that the IDE interrupt
handling can take a long time, regardless of whether it unmasks IRQs or not.
And if that IDE interrupt interrupts a serial interrupt, then the serial
stuff won't get handled until the IDE stuff completes.  Thus the problem.

The "fix" could be to have the serial IRQ handler never unmask interrupts,
but that's a bit unsociable to others.  The IDE stuff really needs to not
do so much during the actual IRQ handler.

Ingo's RT patches would probably fix all of this.
 

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