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

David P. Reed
2007-12-08T20:47:59Z

I am going to do a test on another "unused" port.

However, I realized as I was thinking about this. 0x80 is the
"diagnostic device" port. It is not an "unused" port.

Normally, Linux would support a device like the diagnostic device by
providing a character device, called /dev/post-diagnosis (for the
power-on test diagnostic). That device would reserve port 80 for its
use, and the driver could be loaded if there was such a device.

Now one possibility is that my laptop contains a diagnostic code device
that stores all the out's to port 80 (documented only to the designers,
and kept "secret"). That device may need "clearing" periodically,
which is perhaps done by the SMM, which is turned off when I go into
ACPI-on state. Or maybe it is designed to be cleared only when the
system boots at the beginning of the BIOS. What happens when (as
happens in hwclock's polling of the RTC) thousands of in/out*_p calls
are made very fast? Well, perhaps it is not cleared quickly enough, and
hangs the bus.

The point here is that Linux is NOT using a defined-to-be "unused"
port. It IS using the "diagnostic" port, and talking to a diagnostic
device that *is* used, and may be present.

Just doesn't seem clean to me.

So I'd suggest 2 actions:

1) figure out a better implementation of _p that is "safe" and doesn't
use questionable heuristics. udelay seems reasonable because it doesn't
drive contention on the busses on SMP machines, but perhaps someone has
a better idea.

2) Start a background task with the maintainers of drivers to clean up
their code regarding these short delays for slow devices (note that it's
never because the *bus* is slow, but because the *device* is slow.)
Perhaps this could be helped by "deprecating" the _p calls and
suggesting an alternative that requires the coder to be precise about
what the delay is for, and how long it is supposed to be, perhaps on a
per-machine basis.