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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Alan Cox <alan@...>
Cc: Andi Kleen <andi@...>, <linux-kernel@...>, Thomas Gleixner <tglx@...>, Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>
Date: Saturday, December 8, 2007 - 3:25 pm

Alan Cox wrote:
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 
in any early manual for an IBM machine.

The ISA bus supported unterminated transactions safely.   That allowed 
some clever folks to design BIOS diagnostic tools that optionally 
plugged into the bus.

In any case, my machine does not have an ISA bus.  Why should it?  It's 
a laptop!

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 
understood hardware threw in the _p "just to be safe".  Well, it's 
neither safe, nor is it economical of code or data.  It hangs up the bus 
on an MP machine, for example, even when it works, to do the delay by 
"outb al,80h"

Worse, the actual requirements of the gazillions of inb_p instructions 
for delays are not documented in the code!  This is interesting, because 
the number of devices likely to need a delay after providing data on an 
"in" instruction is very likely to be near zero.  After all, the device 
has already serviced the bus and delivered data!  Why put many 
microseconds into the bus, locking out other ISA transactions (and PCI 
maybe too) with an out to port 80?

Some of the code in linux is really nice, really clean, really 
well-thought out.  Some is ... well, I'm not trolling for a fight.



--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Tue Dec 11, 11:41 am)
More info on port 80 symptoms on MCP51 machine., David P. Reed, (Wed Dec 12, 4:07 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Wed Dec 12, 4:26 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Wed Dec 12, 4:58 pm)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Wed Dec 12, 5:05 pm)
Re: More info on port 80 symptoms on MCP51 machine., Chuck Ebbert, (Fri Dec 14, 6:05 pm)
Re: More info on port 80 symptoms on MCP51 machine., Rene Herman, (Sat Dec 15, 3:22 am)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Wed Dec 12, 5:12 pm)
RE: More info on port 80 symptoms on MCP51 machine., Allen Martin, (Sat Dec 15, 6:34 pm)
Re: More info on port 80 symptoms on MCP51 machine., H. Peter Anvin, (Sat Dec 15, 6:46 pm)
Re: More info on port 80 symptoms on MCP51 machine., David P. Reed, (Wed Dec 12, 4:37 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Tue Dec 11, 4:27 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., linux-os (Dick Johnson), (Wed Dec 12, 9:11 am)
Attitude problems., David P. Reed, (Wed Dec 12, 3:42 pm)
Re: Attitude problems., linux-os (Dick Johnson), (Wed Dec 12, 4:31 pm)
Re: Attitude problems., linux-os (Dick Johnson), (Fri Dec 14, 12:01 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., Dr. David Alan Gilbert, (Sun Dec 9, 9:41 am)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., David P. Reed, (Sat Dec 8, 3:25 pm)
Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern A..., Lennart Sorensen, (Tue Dec 11, 11:14 am)