Date: Sat, 10 Oct 1998 04:19:18 +0800 From: Peter Wemm <peter@netplex.com.au> To: Guy Helmer <ghelmer@scl.ameslab.gov> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-current@FreeBSD.ORG Subject: Re: Kernel backtrace for recurring page fault panic Message-ID: <199810092019.EAA11356@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 09 Oct 1998 14:06:51 EST." <Pine.SGI.3.96.981009135422.5543A-100000@demios.scl.ameslab.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
Guy Helmer wrote:
> On Fri, 9 Oct 1998, Bruce Evans wrote:
>
> > >I finally have a backtrace for a page fault panic that has been bothering
> > >me under -current for months (it only happens when I use cvsup); this
> > >kernel was built from current sources on October 2. It appears that there
> > >are two page faults, the first occuring in tulip_txput and the second in
> > >tsleep. Is this of value to the kernel gurus?
> >
> > I think this panic was reported by someone else. tulip_txput() calls
> > vtophys() on an invalid address for some unknown reason. The pagefault in
> > tsleep() is not interesting (sync() can not be called from an interrupt
> > handler).
>
> Thanks for the help, Bruce. I see something in if_de.c:tulip_txput() that
> doesn't seem correct; perhaps it is related to the problem?
>
> In tulip_txput, m0 is set to point at m at line 4267, but if "segcnt >
> TULIP_MAX_TXSEG" at line 4363, it looks like the original mbuf chain is
> freed in tulip_mbuf_compress() after a new chain is constructed. m0
> is not reset to point to the new mbuf chain, but m0 is used in the do loop
> at line 4350 -- is this OK?
I've been running this diff locally for a while:
Index: if_de.c
===================================================================
RCS file: /home/ncvs/src/sys/pci/if_de.c,v
retrieving revision 1.86
diff -u -r1.86 if_de.c
--- if_de.c 1998/09/24 13:31:01 1.86
+++ if_de.c 1998/10/09 20:41:34
@@ -4264,8 +4264,8 @@
* latter case we have to recopy.
*/
#if !defined(TULIP_BUS_DMA) || defined(TULIP_BUS_DMA_NOTX)
- m0 = m;
again:
+ m0 = m;
#endif
d_status = 0;
eop = nextout = ri->ri_nextout;
This change is specific to the non-bus-dma version of the driver. It's a
backout of one of Matt's changes some time ago that I wasn't sure about.
I suspect this may be related to your problem.
There are some other bugfixes that Matt has made to the if_de driver in
NetBSD that we should pick up, but I wasn't game to fiddle with the driver
this late. I've got a pair of cards for testing, but they are both the
same chip revision - it works for me, but there's no telling what it'll do
on the rest. It looks like it'll fix a few things though.
> Thanks again,
> Guy
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810092019.EAA11356>