Date: Fri, 21 Jul 2000 20:54:13 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: David Greenman <dg@root.com> Cc: Mike Smith <msmith@FreeBSD.ORG>, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <Pine.LNX.4.10.10007212042590.1573-100000@linux.local> In-Reply-To: <200007202205.PAA07882@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10007212042590.1573-100000>