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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux