On 21-02-08 17:24, Peter Teoh wrote:
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
The issue is spread out over quite a few threads in fact. It started here:
http://www.gossamer-threads.com/lists/linux/kernel/851070?do=post_view_threaded
and spawned children such as:
http://www.gossamer-threads.com/lists/linux/kernel/854593?do=post_view_threaded
http://www.gossamer-threads.com/lists/linux/kernel/858547?do=post_view_threaded
and even an LKML wide timing test at:
http://www.gossamer-threads.com/lists/linux/kernel/852672?do=post_view_threaded
http://www.gossamer-threads.com/lists/linux/kernel/853069?do=post_view_threaded
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?
Another CPU will stall when it also tries to access the bus. That in itself
is undesirable (you don't want stalled CPUs) but it minimises races windows
when drivers don't actually do proper locking themselves. So, you don't want
that sideeffect, but Alan Cox (see somewhere in those threads) was in fact
finding locking bugs and therefore it's a issue in the replacement.
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
Posting means flushing, basically. The PCI bus might complete a transaction
from a host point of view before the data has hit the device itself. A sort
of PCI bus cache, if you will. PCI posting means flushing this "cache".
A read from the same PCI device is the generic method for forcing PCI write
posting. When you need to make sure that all issued writes have made it to
the actual device before subsequent ones, you issue a read to the device as
a posting barrier. Also, a write that flows through the PCI-ISA bridge
functions as a posting barrier and that's the side-effect of the 0x80 write.
It's again not something that_should_ be a problem, but it changes behaviour
(and timing) and is as such relevent to the issue.
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?
David P. Reed debugged that somewhat:
http://www.mail-archive.com/linux-kernel@xxxxxxxxxxxxxxx/msg248974.html
Now I understand, 0xed has puzzled me a long time. But what are all
these about - bottomlines is to create I/O delay right
To create a delay of fairly precisely 1 us yes.
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?)
Well, no, it's about address setup and timeout delays indeed and about how
the specifications of the ISA bus make (or made...) this a well defined and
CPU-speed independent way for creating those short delays. An access to a
non-existent port on ISA takes some 8 bus cycles for address setup and
timeout which with the regular ISA bus speed of 8 MHz gets us our 1 us.
The specific bus having defined and "unchanging" timing characteristics is
vital in this, so you can't just use anything else.
(note: in all of this there are quite a few quotes around words such as
"standard", "unchanging", "specified", "guaranteed" but that's just the ugly
way of the legacy PC. In all casees you can read the quotes as "not really,
but still good enough").
Rene.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
