Hi,

I'm tracking the problem about Intel EtherExpressPro (fxp) on CATS.
It is probed and configured normally, but the performance is awful.
There were the similar discussion on this list about this:
http://mail-index.netbsd.org/port-arm32/1999/11/08/0000.html

According to the archives, this problem is caused by
some DMA cache coherency. 

In <199911121024.KAA20182@cam-mail1.cambridge.arm.com>
Richard Earnshaw <rearnsha@arm.com> wrote:

> 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.

I think the fxp problem is the above case.

Usually, kernel momory which is used to pass some parameters
via DMA is allocated by bus_dmamem_alloc(9) and mapped
bus_dmamem_map(9) as BUS_DMA_COHERENT, so cache flush
oprations are not required so strictly.

But the RFA (Receive Frame Area) memory for fxp
is allocated in normal mbuf, so it is cacheable.

In fxp_intr(), rfa->rfa_status is checked by the kernel,
but if the packet reception is not complete, it will be updated
later by fxp via DMA. I guess cache flush is required at this
point and the attached patch seems to fix this problem.

Comments?
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp


Index: i82557.c
===================================================================
RCS file: /cvs/cvsroot/syssrc/sys/dev/ic/i82557.c,v
retrieving revision 1.33
diff -u -r1.33 i82557.c
--- i82557.c	2000/05/27 00:55:42	1.33
+++ i82557.c	2000/06/07 14:00:35
@@ -916,6 +916,11 @@
 
 			if ((rxstat & FXP_RFA_STATUS_C) == 0) {
 				/*
+				 * RFA will be updated later by fxp
+				 * so we have to sync it.
+				 */
+				FXP_RFASYNC(sc, m, BUS_DMASYNC_PREREAD);
+				/*
 				 * We have processed all of the
 				 * receive buffers.
 				 */