Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

[Andi Kleen <andi@firstfloor.org>]

On Sat, Dec 08, 2007 at 02:25:02PM -0500, David P. Reed wrote:
> 
> 
> Alan Cox wrote:
> >
> >0x80 should be fine for anything PC compatible anyway, its specifically
> >reserved as a debug port and supported for *exactly* that purpose by
> >many chipsets.
> >
> >  
> Disagree. The definitions of PC compatible are quite problematic.   I 
> have the advantage over some of you young guys, in that I actually wrote 
> code on one of the first 5 breadboard IBM PCs on the planet at Software 
> Arts, Inc. and I was directly involved in hardware spec projects with 
> the original IBM and Compaq engineers.  No one actually defined the port 
> numbered 80h as a "standard" for anything.  You won't find it documented 

It is a defacto standard for quite some time. Many motherboards
even come with builtin port 80 displays and port 80 cards are a standard
diagnostic tool. Pretty much all the of the standard BIOS
write diagnostic messages to port 80. While in theory a vendor
could change those BIOS they are pretty unlikely to do that.

Have you tried yet as someone asked earlier if using another 
free port that also leads to aborts causes the hang too?
If yes you would know for sure it is nothing on port 80,
but something not liking aborts (similar to the problem Eric B.
found earlier) 

Anyways using udelay is likely the way to go for modern
systems.

> Now the interesting thing is that I have been scanning the source code 
> of Linux, and I find gazillions of inb_p outb_p and so forth 
> instructions where they have NO value.   It's as if some hacker who half 

It is hard to know afterwards. In the past we definitely had systems
who needed such delays.  But some of it might be what you said.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/