Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Oct 2002 16:24:22 +0000
From:      Ian Dowse <iedowse@maths.tcd.ie>
To:        pawmal@unia.3lo.lublin.pl
Cc:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/42260: 4.6-STABLE kernel panic, fxp related 
Message-ID:   <200210281624.aa28226@salmon.maths.tcd.ie>
In-Reply-To: Your message of "Wed, 04 Sep 2002 00:17:23 %2B0200." <20020903221718Z2129491-22726%2B13@mx1.lublin.pl> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020903221718Z2129491-22726+13@mx1.lublin.pl>, =?ISO-8859-2?Q?Pawe
=B3_Ma=B3achowski?= writes:
>On 3 Sep 02, at 16:22, Ian Dowse wrote:
>> Could you try using the latest 4.6-STABLE source, but with the old
>> version of if_fxp.c? Grab it from cvsweb at
>
>But let's go back to this PR. Todays RELENG_4, 4.7-PRERELASE
>with older version of if_fxp.c (1.110.2.23) looks stable for
>me. I'm happy.
>
>What now?
>Problem is specific only to one combination of my machines.
>I have no idea, how this combinaction could affect the newer
>fxp driver and cause a kernel panic...

Hi,

If possible, could you try the following patch against the latest
revision of if_fxp.c. This should limit the abuse of the reserved
status bit to the DEVICE_POLLING case. I haven't tested this patch
beyond compiling it, so be prepared for problems. I'll push to get
this committed if it solves the problem for you, as I hate to see
this kind of hack remaining in the driver for one of FreeBSD's most
recommended NICs.

Ian

Index: if_fxp.c
===================================================================
RCS file: /home/iedowse/CVS/src/sys/dev/fxp/if_fxp.c,v
retrieving revision 1.110.2.25
diff -u -r1.110.2.25 if_fxp.c
--- if_fxp.c	24 Sep 2002 23:45:16 -0000	1.110.2.25
+++ if_fxp.c	28 Oct 2002 15:57:22 -0000
@@ -1288,15 +1288,22 @@
 	 * Process receiver interrupts. If a no-resource (RNR)
 	 * condition exists, get whatever packets we can and
 	 * re-start the receiver.
+	 */
+
+#ifdef DEVICE_POLLING
+	/*
 	 * When using polling, we do not process the list to completion,
 	 * so when we get an RNR interrupt we must defer the restart
 	 * until we hit the last buffer with the C bit set.
 	 * If we run out of cycles and rfa_headm has the C bit set,
 	 * record the pending RNR in an unused status bit, so that the
 	 * info will be used in the subsequent polling cycle.
+	 *
+	 * XXX there is absolutely no guarantee that this reserved bit
+	 * will be ignored by the hardware!
 	 */
-
 #define	FXP_RFA_RNRMARK		0x4000	/* used to mark a pending RNR intr */
+#endif
 
 	for (;;) {
 		m = sc->rfa_headm;
@@ -1311,8 +1318,10 @@
 		if ( (rfa->rfa_status & FXP_RFA_STATUS_C) == 0)
 			break;
 
+#ifdef DEVICE_POLLING
 		if (rfa->rfa_status & FXP_RFA_RNRMARK)
 			rnr = 1;
+#endif
 		/*
 		 * Remove first packet from the chain.
 		 */
@@ -1346,15 +1355,19 @@
 		}
 	}
 	if (rnr) {
+#ifdef DEVICE_POLLING
 		if (rfa->rfa_status & FXP_RFA_STATUS_C)
 			rfa->rfa_status |= FXP_RFA_RNRMARK;
 		else {
+#endif
 			fxp_scb_wait(sc);
 			CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,
 			    vtophys(sc->rfa_headm->m_ext.ext_buf) +
 				RFA_ALIGNMENT_FUDGE);
 			fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START);
+#ifdef DEVICE_POLLING
 		}
+#endif
 	}
 }
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200210281624.aa28226>