From owner-freebsd-hackers Mon Jun 26 13:17:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from front5m.grolier.fr (front5m.grolier.fr [195.36.216.55]) by hub.freebsd.org (Postfix) with ESMTP id B963337BD19 for ; Mon, 26 Jun 2000 13:17:31 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from Guyancourt-1-175.club-internet.fr (Guyancourt-1-175.club-internet.fr [195.36.205.175]) by front5m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA16696; Mon, 26 Jun 2000 22:17:11 +0200 (MET DST) Date: Mon, 26 Jun 2000 21:55:19 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Mohana Krishna Penumetcha Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCI transaction ordering!!! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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