Date: Mon, 26 Jun 2000 21:55:19 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Mohana Krishna Penumetcha <pmk@sasi.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI transaction ordering!!! Message-ID: <Pine.LNX.4.10.10006262035350.1842-100000@linux.local> In-Reply-To: <Pine.LNX.4.10.10006261442590.25550-100000@pcd134.sasi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jun 2000, Mohana Krishna Penumetcha wrote:
> hi,
>=20
> HP-UX device driver reference manual says,=20
>=20
> =09"The side-effects of any write are not guaranteed to happen
> immediately. Writes are posted; they will complete eventually"
>=20
> to make sure all writes are flushed from the queue, it suggests to perfor=
m
> a read operation.
>=20
> i would like to know if the above behaviour is same across all operating
> systems, esp if it is the same in FreeBSD case also??
It does not depend on the O/S. It is a PCI optimization that addresses
bridges (PCI-host bridges and PCI-PCI bridges) and performing a read
transaction (useful or dummy) is the way required by PCI specifications to
flush posted transactions.
Some bridges may also elect to flush posted transactions on some event
like when IRQ is raised, but this is broken approach due to the fact that
IRQ lines can be shared by several PCI devices and have no dependency with
lines used for transactions (INTR lines look like side-band signals on
PCI). On PCI, only PCI transactions (except interrupt acknowledge) can act
as synchronisation events and read transactions (useful or dummy) have to
be used when the software or the PCI device requires posted writes to be
flushed.
If you are interested in PCI, I suggest you to read the PCI
specifications. May-be, you will have to read them several times prior to
having a reasonnable understanding of them. :-) If this happens, you
should not have to worry, since it seems to me that they have been often
not well understood even by hardware designers and architects. ;-) (I may
be disagreed here)
As a result of this misunderstanding probably, some real hardwares are not
full PCI compliant (or not enough PCI-friendly :-)). For example regarding
flushing of posted transactions:
PCI specifications require the following when a read is attempted through
a bridge (I intentionnaly donnot speak about delayed transactions for
simplicity):
1) Flush posted writes to the destination BUS
2) Perform the read to the device (on the destination BUS).
3) Flush posted writes to the originating BUS.
(at least those attempted prior to the read having been accepted by
the device targetted by the read)
4) Complete the read at the originating device (on the originating BUS).
On some systems, as Alpha for example, (3) is not required to be
performed. As a result, if the device does not flush posted transactions
prior to telling the software driver about events (as completions), stale
data can be read from memory by the software driver.
When (3) is performed, the device is only required to move data to memory
and set some flag in some proper order and the flushing of posted
transactions that ensures no stale data will be read can be achieved from
the software driver (no flushing is needed from the device).
By the way, the documentations I have read about bridges and architectures
let me under the impression that numerous PCI device drivers (not only on
BSD systems) are broken (in race) regarding transaction posting issues. In
my opinion, a PCI device driver that just don't care about posted
transactions has every chance to be broken, at least on some architecture
or using some bridge. Using legacy IO method rather than MMIO does not
make it more safe, since host bridges are also allowed to post IO writes.
Speaking about Intel hardware and architecture:
- IA32 does not reorder STOREs when they are carried out to the system=20
BUS, neither it allows LOADs to pass STOREs.
- Intel host bridges are, at least on paper, PCI compliant regarding=20
ordering rules and donnot post IO write transactions.
Such strong ordering situation allows PCI devices and drivers designed
with ISA in mind to work reasonnably, but if you move such a device and/or
driver to MMIO world with posted writes or to systems that follow ordering
rules weaker than PCI requirements, races will likely appear.
G=E9rard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10006262035350.1842-100000>