On 21-02-08 09:45, Peter Teoh wrote:
I have many doubts over this email chain:
Things like this are best off being CCed to kernelnewbies -- that way, more people who might be interested get to read it, and might expand or follow up, or...
a. port 0x80 - it is a debug port from Intel chipset right?
No, port 0x80 is the old BIOS POST diagnostics port and (except for the case that triggered this thread) isn't handled by anything. A PC BIOS (generally) writes progress numbers to this port while it's busy POSTing (Power On Self Test) so that when you have a POST diagnostics display board installed, you get to see what the BIOS is up to even before it has VGA available to display progress.
It not being handled by anything _other_ than a POST diagnostics board and this fact being sort of guaranteed by the BIOS using it as such is in fact the point of using it for an I/O delay, see below.
from my colleagues all the debug messages from POST are seen through here? how do we extract it?
By looking at the LED display on the POST diagnostics board if you have one installed -- if there's nothing listening on port 0x80, the writes just go nowhere, and you can't "extract" them from anywhere either.
b. so what happen if we write ro read to this port?
W: POST board displays (and/or stores) the value if installed, otherwise the write dies on ISA (or LPC, these days) which just costs a bit of time -- fairly precisely 1 microsecond on a standard ISA/LPC bus. R: The read dies -- perhaps on ISA/LPC, or perhaps not, if the chipset chooses to not forward the read onto ISA/LPC. Only the write direction is "guaranteed" to reach ISA/LPC due to the POST board use and as such it has no well defined timing characteristic either.
c. what is this "delay" thing about? why do we need delay? why is the hardware signal not able to coordinate among the different read/write waiting among themselves?
Because PC hardware, legacy PC hardware most certainly, is a major bunch of major crap. Legacy PC hardware, the stuff that originally sat on the ISA bus, sometimes -- often -- needed manual delays between accesses to allow the hardware time to act on a write before it could respond correctly to the next read or write. The needed delay could be specified in absolute time (a number of microseconds) or with the hardware synchronized to the bus, could be specified in bus cycles.
In either case a low overhead delay is needed and back then CPUs didn't have a TSC or anything that could be used for precise, short delays and arguably wouldn't be correct anyway with delays specified in bus cycles.
People routinely used reads or writes to I/O ports as the delay method of choice and this works well in practice. Sometimes you can sync with the actual piece of hardware you're waiting for by reading from its own registers, sometimes you just want to sync with the bus meaning any port without side-effects might do. An _unused_ port moreover gives a very specific delay due to guaranteed timeout behaviour on the bus, and with a normal ISA bus this amounts to almost exactly 1 microsecond.
With the demise of actual ISA, most of these specified delays went away as well but writes to port 0x80 retain the behaviour due to chipsets forwarding them onto ISA/LPC precisely for use by the POST diagnostics board (yes, if you actually have one of those installed the timing changes, but we'll ignore that for a bit).
For the last 15 years or so Linux has been using the port 0x80 write as an I/O delay and while many uses of the delay haven't been needed at any time on any machine, some of the delays are on some of the machines and given that this is all legacy stuff now it's hard to make sure you're not breaking anyone when changing it and people are therefore being cautious. You don't want a 10 year old machine that might get installed just for the heck of it next year with a new kernel to break and certainly not with the kind of hard to debug problems that timing issues tend to cause. Moreover, writing to an I/O port has side-effects such as locking the bus on SMP machines and posting PCI writes and this adds to the fear, uncertainty and doubt.
Unfortunally though, HP/Compaq is marketing a series of laptops where something is listening on port 0x80 and that eventually locks up after enough writes to it so it needs changing on those at least.
d. what is this DMI standard about? what does it have to say about port 80?
Not a thing. DMI stands for Desktop Management Interface and is just a way to retrieve information about the system. For example, you can retrieve from it the fact that you're running on one of those HP/Compaq laptops by looking at the motherboard vendor and type strings abd then decide to not do port 0x80 writes based on that. This is what the original version of the patch at the moment in .25-rc does -- it exchanges port 0x80 for port 0xed when on one of the identified machines. 0xed is another port that's sometimes used for the POST diasgnostics (by some Phoenix BIOSes) and which has been determined to work for the afflicted machines.
It does not change timing, nor any of the side effects meaning this is a low risk change but it's messy and fairly unmaintainable to have to manually specify machines on which to change behaviour like that so it's not considered a good solution.
e. in the PIT another port (0x61) is used, what is that port about?
Port 0x61 is a miscelaneous functions port and one of its functions is providing a bit to route PIT channel 2 to the PC speaker (which is the way the PC speaker produces sound). So it's not really a PIT function itself.
If too elaborate to answer quickly or if u are busy, u can just point me some references or chipset documentation, i really am losts.....thanks a lot Rene.
Who needs lunch.... Hope it helps. Rene. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
