From owner-freebsd-alpha Fri Jul 14 13:31:50 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from front2.grolier.fr (front2.grolier.fr [194.158.96.52]) by hub.freebsd.org (Postfix) with ESMTP id A3E1C37C6CF; Fri, 14 Jul 2000 13:31:43 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from Guyancourt-1-234.club-internet.fr (Guyancourt-1-234.club-internet.fr [195.36.205.234]) by front2.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id WAA29945; Fri, 14 Jul 2000 22:31:23 +0200 (MET DST) Date: Fri, 14 Jul 2000 22:10:37 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: Andrew Gallatin Cc: mjacob@feral.com, David Greenman , Mike Smith , Bernd Walter , freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE In-Reply-To: <14703.24005.384580.704375@grasshopper.cs.duke.edu> 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 Fri, 14 Jul 2000, Andrew Gallatin wrote: > Matthew Jacob writes: > >=20 > > > "Providing support" to me means not only getting it working, but = also > > > making sure that it continues to work over time and putting the effo= rt in > > > to fix it if it should break. > >=20 > > Well, this starts us diverging toward meta-issues. > >=20 > > I'm sorry you don't wish to support this on the alpha. >=20 > For what its worth, I just stole an fxp from an x86. I'm going to try=20 > to getting working, but I make no promises. I have no documentation about this chip, but last time I looked into the code of this driver, I seem to understand that the device and CPU use some list or queue in main memory. In such situation, software drivers must be aware of what memory accesses are ATOMIC (also from BUS) and what are not. They must also be aware that modern CPUs reorder LOADs and STOREs. The only thing I saw that seem to deal with ordering is some 'volatile'. As you know, 'volatile' is just some compiler optimization barrier and should not be used any longer in drivers. We should instead use explicit compiler barriers and explicit memory barriers when needed. For example, imagine the following scenario: Device that does the right thing from PCI BUS: =09write USER DATA to memory =09write STATUS DATA to memory =09write COMPLETION FLAG to memory (A)->=09perform a READ to flush posted writes =09set INTERRUPT FLAG C code ordering unaware: LOOP: =09read INTERRUPT FLAG from IO register =09if not set RETURN =09read COMPLETION=09FLAG from memory =09read STATUS DATA =09etc ... =09goto LOOP C code ordering aware: LOOP: =09read INTERRUPT FLAG from IO register =09if not set RETURN =09clear(write) INTERRUPT FLAG (if the read is not self-clearing) (B)->=09perform a READ from BUS to flush posted writes =09read COMPLETION=09FLAG from memory (C)->=09MEMORY BARRIER =09read STATUS DATA from memory =09etc ... =09goto LOOP (A) and (B) posted write flushing prevents from losing interrupt condition on bridges that donnot flush posted writes UPSTREAM, as on Alpha. On bridges that also flushed posted write UPSTREAM, only (A) or (B) is=20 needed. Basically if the write that CLEARS the INTERRUPT FLAG is to long delayed, it may just clear the INTERRUPT FLAG that address the NEXT completion. The MEMORY BARRIER protects against not desirable reordering of LOADS by the CPU. Basically the CPU can read the STATUS DATA prior to the COMPLETION FLAG from memory and then the C code may just have to deal with stale STATUS DATA. The above is an example. May-be it does not apply to the fxp driver. I know that I am paranoid ;-), but it seems to me that numerous drivers are not carefull enough about ordering. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message