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  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:	Fri, 07 Dec 2007 17:28:14 +0100
From:	Rene Herman <>
To:	"David P. Reed" <>
CC:	Andi Kleen <>,,
	Thomas Gleixner <>,
	Ingo Molnar <>,
	"H. Peter Anvin" <>
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64
 with MCP51 laptops

On 07-12-07 16:43, Rene Herman wrote:

> On 07-12-07 15:54, Andi Kleen wrote:
>>> My machine in question, for example, needs no waiting within 
>>> CMOS_READs at all.   And I doubt any other chip/device needs waiting 
>>> that isn't 
>> I don't know about CMOS, but there were definitely some not too ancient
>> systems (let's say not more than 10 years) who required IO delays in the
>> floppy driver and the 8253/8259. But on those the jumps are already
>> far too fast.
> Also see Alan's replies in the thread I posted a link to:
> Also 8254 (PIT) at least it seems.

By the way, David, it would be interesting if you could test 0xed. If your 
problem is some piece of hardware getting upset at LPC bus aborts it's not 
going to matter and we'd know an outb delay is just not an option on your 
system at least. You said you could quickly reproduce the problem with port 

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists