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

Rene Herman
2007-12-07T07:18:18Z

On 07-12-07 06:54, David P. Reed wrote:

> Pardon my ignorance, but is port 0xed really safe to push an out cycle
> at across the entire x86_64 family?

Please do not top-post. Who knows, probably not. You just experienced that
0x80 is apparently not safe for you and that one's the conventional choice
so it's likely that someone somewhere will have problems with 0xed as well.

That's why I adviced you'd test and see what blows up and suggested that in
the absence of better fixes a 0x80/0xed port choice might be able to hang
off machine types as retrievable from DMI or something.

The better fix would probably be to simply udelay(1) but you need calibrated
timers before you can do that and some googling leads me to believe that's
why it's not today. There's also a possible issue in that an I/O access
might serve as a method of flushing forwarding buffers on a PCI bridge but I
have no idea if that's a real issue (and if it is, an inb() should suffice
as well).

> How long must real _p pauses be in reality?

8 ISA bus cycles is the intended delay it seems which at a typical ISA bus
speed of 8 MHz amounts to 1 us.

> (and who cares about what the code calls "really slow i/o").

Paranoid programmers and those that need to delay for 4 us.

> Why are we waiting at all? I read the comments in io_64.h, and am a bit
> mystified. Does Windoze or DOS do this magical mystery wait?

The CMOS example at hand is the standard example. It's accessed through an
index/data register pair. You need to be sure that the RTC has switched the
correct internal register to the data register before you poke at it or
you may read/write the wrong one.

Now, as said, I can't say I've ever in fact caught _any_ piece of hardware
with its pants down like that and needing this for actual RTC/CMOS could as
far as I'm aware be more of a left-over from The Olden Days with a bus more
or less directly tied to the 8086 than sensible for anything on which Linux
could run. Hard to test though and certainly for generic outb_p use.

Yes, DOS or at least many programs that ran under it did very similar things
but DOS ofcourse originated on those first PCs.

> Anyway, the virtualization hooks in 32-bit x86 almost make it possible
> to isolate this simply - maybe - after the merge of 32/64 being
> contemplated.
>
> And anyone who knows what the chipset might be doing with the 80 port
> rather than POST codes, perhaps could contribute. Any nvidia folks who
> know what's happening under NDA? Any Phoenix BIOS types?

It's fairly surprising that 0x80 is given you trouble. It's a very well
known legacy port. Even though it may not be all that sensible a thing today
I'd say that if your machine put anything other than an actual integrated
POST monitor on port 0x80 it in fact fucked up.

> I think the worst of the problems would be fixed by changing just the
> CMOS_READ/CMOS_WRITE macros. But the danger lingers in the *_p code.

Rene.