From owner-freebsd-current Fri Oct 9 13:48:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16473 for freebsd-current-outgoing; Fri, 9 Oct 1998 13:48:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA16398 for ; Fri, 9 Oct 1998 13:47:31 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id EAA11356; Sat, 10 Oct 1998 04:19:18 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810092019.EAA11356@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Guy Helmer cc: Bruce Evans , freebsd-current@FreeBSD.ORG Subject: Re: Kernel backtrace for recurring page fault panic In-reply-to: Your message of "Fri, 09 Oct 1998 14:06:51 EST." Date: Sat, 10 Oct 1998 04:19:18 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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