> 
> >Opps I'll fix that. I can confirm that this does not fix the described
> >problem with the fxp driver (I've dug out a card).
> 
> 
> No, it doesn't fix the problem. I tried it too.

I said it wouldn't... :-|

> 
> At the moment what does fix it (with an unmodified "bus_dmamap_sync" ) is in
> the fxp driver
> (if_fxp.c) "fxp_intr" function, the first occurrence of "bus_dmamap_sync"
> after "rcvloop:"
> which is originally
> bus_dmamap_sync(BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
> 
> If ONLY this occurrence is changed to:
> 
> bus_dmamap_sync(BUS_DMASYNC_PREREAD) to force a cache purge before
> processing incoming ethernet frames.
> 

Ok, let's assume for a moment that that call really is a "POST" call, and 
that we are about to recover a buffer that has just been dma'ed in (It 
certainly looks like it from a quick look at the code).  Clearly, at this 
point it will fail if we have data in the cache for that virtual address.  
I can think of four possible reasons for this (and the fourth is *very* 
improbable).

1) We didn't clean the cache before we started...
2) We did clean the cache, but then we tried to peek the memory in 
question while the transfer was in progress (this would load incomplete 
data into the cache.
3) We have somehow messed with the virtual address (or had something else 
at that virtual address which wasn't flushed out.  This is, I think, 
possible, but improbable, especially if the problem is very repeatable.  
However, this might explain why the code would work on an x86 with a 
physically mapped cache, but not on a StrongARM where the cache is virtual.
4) The cache cleaning routines are not working reliably (As I said, very 
unlikely).


R.