cube@cubidou.net wrote:

> RX is definitely the problem.  When I experience such stalls (which seem
> to happen as soon as a high packet rate comes in), I can still see
> packets coming out through nfe.  I don't remember if I checked with
> tcpdump, but pinging the broadcast address does blink the whole switch,
> so I'm quite positive.

If it's caused by some race condition, how about the attached one?

BTW, which is your port, i386 or amd64?
With a quick glance there is not any improper reordering around
descriptor access even without volatile on i386, but I'm not sure.
---
Izumi Tsutsui


Index: if_nfereg.h
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_nfereg.h,v
retrieving revision 1.3
diff -u -r1.3 if_nfereg.h
--- if_nfereg.h	9 Jan 2007 10:29:27 -0000	1.3
+++ if_nfereg.h	4 Feb 2007 05:01:10 -0000
@@ -144,9 +147,9 @@
 
 /* Rx/Tx descriptor */
 struct nfe_desc32 {
-	uint32_t	physaddr;
-	uint16_t	length;
-	uint16_t	flags;
+	volatile uint32_t	physaddr;
+	volatile uint16_t	length;
+	volatile uint16_t	flags;
 #define NFE_RX_FIXME_V1		0x6004
 #define NFE_RX_VALID_V1		(1 << 0)
 #define NFE_TX_ERROR_V1		0x7808
@@ -155,12 +158,12 @@
 
 /* V2 Rx/Tx descriptor */
 struct nfe_desc64 {
-	uint32_t	physaddr[2];
-	uint32_t	vtag;
+	volatile uint32_t	physaddr[2];
+	volatile uint32_t	vtag;
 #define NFE_RX_VTAG		(1 << 16)
 #define NFE_TX_VTAG		(1 << 18)
-	uint16_t	length;
-	uint16_t	flags;
+	volatile uint16_t	length;
+	volatile uint16_t	flags;
 #define NFE_RX_FIXME_V2		0x4300
 #define NFE_RX_VALID_V2		(1 << 13)
 #define NFE_RX_IP_CSUMOK	(1 << 12)