From owner-freebsd-alpha Fri Jul 21 12:14:57 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from front5.grolier.fr (front5.grolier.fr [194.158.96.55]) by hub.freebsd.org (Postfix) with ESMTP id 21B4137BE0D; Fri, 21 Jul 2000 12:14:49 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from nas1-142.cgy.club-internet.fr (nas1-142.cgy.club-internet.fr [195.36.197.142]) by front5.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id VAA18431; Fri, 21 Jul 2000 21:14:32 +0200 (MET DST) Date: Fri, 21 Jul 2000 20:54:13 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: David Greenman Cc: Mike Smith , freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE In-Reply-To: <200007202205.PAA07882@implode.root.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, David Greenman wrote: > >> As a result ( applying to my opinion ;-) ), when a PCI device and its > >> software driver communicates through the main memory, it is _very_ lik= ely > >> memory barrier to be needed in some places so that program-expected > >> ordering as seen from the system BUS will happen. > > > >I am inclined to agree with you that there are probably cases in the fxp= =20 > >driver where the author has made assumptions regarding the x86 normal=20 > >behaviour of retiring writes in program order, however that's not the=20 > >issue that this change is trying to address. >=20 > That is correct. The author assumed that writes would be retired in > order and without any special memory barriers or other synchronization. The memory barrier we must use after having READ the FLAG and prior to=20 READ the associated STATUS DATA is _also_ intended to avoid reodering by=20 the CPU of these 2 kinds of READs. If they are reodered the software=20 driver may read stale STATUS DATA. For software drivers that execute concurrently with the PCI device, the FLAG may be the item that tells about the IO that completed and retired from some completion queue in main memory prior to examining the associated STATUS DATA. By the way, software drivers that behave as the above model may also have to insert a serialisation instruction on PII/PII between the READ of the FLAG and the READ of the STATUS DATA (If PII/PPIII can reorder LOADs). G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message