Date: Fri, 14 Jul 2000 22:10:37 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: mjacob@feral.com, David Greenman <dg@root.com>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, freebsd-alpha@FreeBSD.ORG Subject: Re: fxp0 hangs on a PC164 using STABLE Message-ID: <Pine.LNX.4.10.10007142126001.3025-100000@linux.local> In-Reply-To: <14703.24005.384580.704375@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Jul 2000, Andrew Gallatin wrote: > Matthew Jacob writes: > > > > > "Providing support" to me means not only getting it working, but also > > > making sure that it continues to work over time and putting the effort in > > > to fix it if it should break. > > > > Well, this starts us diverging toward meta-issues. > > > > I'm sorry you don't wish to support this on the alpha. > > For what its worth, I just stole an fxp from an x86. I'm going to try > 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: write USER DATA to memory write STATUS DATA to memory write COMPLETION FLAG to memory (A)-> perform a READ to flush posted writes set INTERRUPT FLAG C code ordering unaware: LOOP: read INTERRUPT FLAG from IO register if not set RETURN read COMPLETION FLAG from memory read STATUS DATA etc ... goto LOOP C code ordering aware: LOOP: read INTERRUPT FLAG from IO register if not set RETURN clear(write) INTERRUPT FLAG (if the read is not self-clearing) (B)-> perform a READ from BUS to flush posted writes read COMPLETION FLAG from memory (C)-> MEMORY BARRIER read STATUS DATA from memory etc ... goto 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 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érard. 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.10007142126001.3025-100000>