Date: Sun, 11 Aug 2002 03:00:12 -0700 From: Luigi Rizzo <luigi@freebsd.org> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: Mike Tancsa <mike@sentex.net>, stable@freebsd.org Subject: Re: fxp problems with latest stable Re: panics after upgrading to -STABLE Aug 9, 2002 (still something up) Message-ID: <20020811030012.C82972@iguana.icir.org> In-Reply-To: <200208110304.aa47521@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sun, Aug 11, 2002 at 03:04:26AM %2B0100 References: <5.1.0.14.0.20020810210400.0622d770@192.168.0.12> <200208110304.aa47521@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
as i mentioned the problem seems to be related to the m_free() changes.
In any case, coming to your points:
* I cannot guarantee that the NIC will not set the 0x4000 bit in
the descriptor, and the specs are not available so i cannot tell.
It sure seems unused in both the Linux driver (from Intel) and
the FreeBSD driver, and i always saw it as on my hardware.
But i agree that in absence of documentation we should use a
different method to mark a pending RNR. The patch below writes "0"
into the "size" field of a completed rfd to mark a pending RNR.
It should be a lot safer even against future revisions of the chip.
Again I cannot guarantee that the fxp chip does not update that
field after completing reception, but that would be a totally
unreasonable behaviour!
There would be yet another workaround, namely to use an additional
field in the device descriptor to record pending RNR's, but that
would be a little bit trickier.
* the size field is 14 bits, and the linux driver (from Intel) has
/*- RFD misc bits*/
#define RFD_EOF_BIT BIT_15 /* RFD End-Of-Frame Bit */
#define RFD_F_BIT BIT_14 /* RFD Buffer Fetch Bit */
#define RFD_ACT_COUNT_MASK BIT_0_13 /* RFD Actual Count Mask */
also masks it with 0x3fff (although it also does a min() with
some odd value, see below:
data_sz = min_t(u16, (le16_to_cpu(rfd->rfd_act_cnt) & 0x3fff),
(sizeof (rfd_t) - bdp->rfd_size));
so if bit 12 were bogus, it would produce bogus results also after
the min_t() above.
cheers
luigi
On Sun, Aug 11, 2002 at 03:04:26AM +0100, Ian Dowse wrote:
>
> Hi Mike,
>
> thanks for tracking down the commit that caused this. I had a quick
> look at the changes in that revision, and although there were no
> obvious problems I could see, a few things stood out as possible
> candidates:
>
> The FXP_RFA_RNRMARK flag: Luigi, do you have hardware documentation
> for the Intel etherexpress chips that explicitly says that this bit
> is free for use by the device driver? If not, this would be my first
> guess at the problem. A patch that just #if 0's out this code
> (breaking the DEVICE_POLLING case) is below. It would be very useful
> to know if this makes a difference.
>
> Total packet size: the old code used rfa->actual_size & (MCLBYTES - 1)
> and the new version uses a mask of 0x3fff. I assume this is correct,
> but to test if it is the problem, change the 0x3fff to 0x1fff.
Index: if_fxp.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/fxp/if_fxp.c,v
retrieving revision 1.110.2.24
diff -u -r1.110.2.24 if_fxp.c
--- if_fxp.c 9 Aug 2002 02:04:20 -0000 1.110.2.24
+++ if_fxp.c 11 Aug 2002 09:25:43 -0000
@@ -1307,7 +1307,7 @@
if ( (rfa->rfa_status & FXP_RFA_STATUS_C) == 0)
break;
- if (rfa->rfa_status & FXP_RFA_RNRMARK)
+ if (rfa->size == 0) /* XXX we had a pending RNR */
rnr = 1;
/*
* Remove first packet from the chain.
@@ -1342,9 +1342,11 @@
}
}
if (rnr) {
- if (rfa->rfa_status & FXP_RFA_STATUS_C)
- rfa->rfa_status |= FXP_RFA_RNRMARK;
- else {
+ if (rfa->rfa_status & FXP_RFA_STATUS_C) {
+ if (rfa->size == 0)
+ printf("+++ ouch, fxp zeroed size!\n");
+ rfa->size = 0; /* XXX record a pending RNR */;
+ } else {
fxp_scb_wait(sc);
CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,
vtophys(sc->rfa_headm->m_ext.ext_buf) +
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020811030012.C82972>