Appreciate very much for your time spent. Just to provide some further background, the questions arises from this patch (gossamer below can show the long chain of discussion - but lkml.org cannot): http://www.gossamer-threads.com/lists/linux/kernel/881863 On Thu, Feb 21, 2008 at 8:54 PM, Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: > 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 What are the consequences (desirable/undesirable) of locking the bus? > posting PCI writes and this adds to the fear, uncertainty and doubt. > Don't understand - what is meant by "PCI write posting", for example the patch below: http://lists.infradead.org/pipermail/linux-pcmcia/2005-August/002478.html > 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. > Thank you for sharing these rare insights. Any possible reason u can think of why HP/Compaq want to put a listener on port 0x80? > > > 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 Now I understand, 0xed has puzzled me a long time. But what are all these about - bottomlines is to create I/O delay right? And port I/O delay is not the same as delays arising from data/address bus signal - is that correct? (Otherwise any other CPU instructions that access memory could have been used for I/O delay - correct?) > 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. > Thank you Rene. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
