From owner-freebsd-alpha Fri Jul 21 11:52:42 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id AB1A437C151; Fri, 21 Jul 2000 11:52:24 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from nas1-71.cgy.club-internet.fr (nas1-71.cgy.club-internet.fr [195.36.197.71]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id UAA05444; Fri, 21 Jul 2000 20:52:19 +0200 (MET DST) Date: Fri, 21 Jul 2000 20:32:00 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Mike Smith Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE In-Reply-To: <200007202209.PAA00823@mass.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 20 Jul 2000, Mike Smith wrote: > > It is my opinion. You may disagree but it will hard for anybody to > > convince me that I am wrong. ;-) >=20 > On x86, it's very hard for you to be right; the CPU specification and bus > bridge behaviour both guarantee retirement of writes in order of issuance= =2E > This combined with strong cache coherency makes barriers irrelevant on > this platform. Let a PCI device perform: =09STORE A =09STORE B Let the CPU perform and expect: LOAD B LOAD A Let some CPU speculative execution carry out to the system BUS: =09LOAD A =09LOAD B My reading of the the Intel docs didn't convince me that such reordering is not possible. =20 Typically A is some indicator of an IO completion pushed to a completion=20 queue and B is the associated status data. =09 > As far as other platforms are concerned, however, you're quite correct. Are you still so sure. ;-) > There does need to be an extension to the busspace API to define a range= =20 > of host memory with a tag/handle pair for barrier activity. Hmmm... Barrier semantics vary so much between architectures that an unified semantic that also address device driver's concerns (not only CPU<->CPU) is either close to impossible or will just be extremally poor, in my opinion. I will give a single exemple for Alpha: the wmb instruction on Alpha orders memory-like stores and non-memory-like stores _independantly_. That means that the mb instruction must be used as a store barrier when both kinds of stores are addressed at the same time. We can, as a second example, consider: 1) Situations when a real barrier (called serialisation) is needed for IA32 and a mb is needed for Alpha. 2) Situations where only a mb is needed for Alpha but the IA32 does=20 not require serialisation. People who are happy with nightmares can also compare all kind of barriers and implicit ordering rules that are in existence and try to elaborate an unified semantic that is both simple and rich. ;-) And People who are happy with nighmares at the power of two can also read documentations of various existing host-bridges. ;-) Most existing software BUS abstractions mostly address consistency given no concurrency. A common problem with PCI device / software driver pairs is consistency given concurrency, that not only requires CPU barriers to be used but also to be careful about posted write flushing. Basically, also the PCI device and the software driver may have to use some different kind of barriers for consistency given concurrency to happen as expected, by flushing when needed posted write transactions. (using read transactions as we know). The drivers I maintain will always contain any stuff needed for them to be as correct as I want them to be, modulo my knowledge and competence on addressed platforms obviously. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message