From owner-freebsd-current  Fri Oct  9 12:07:08 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA26329
          for freebsd-current-outgoing; Fri, 9 Oct 1998 12:07:08 -0700 (PDT)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from mailhub.scl.ameslab.gov (mailhub.scl.ameslab.gov [147.155.137.127])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA26324
          for <freebsd-current@freebsd.org>; Fri, 9 Oct 1998 12:07:06 -0700 (PDT)
          (envelope-from ghelmer@scl.ameslab.gov)
Received: from demios.ether.scl.ameslab.gov ([147.155.137.54] helo=demios.scl.ameslab.gov)
	by mailhub.scl.ameslab.gov with smtp (Exim 1.90 #1)
	id 0zRhsJ-0001US-00; Fri, 9 Oct 1998 14:06:51 -0500
Date: Fri, 9 Oct 1998 14:06:51 -0500 (CDT)
From: Guy Helmer <ghelmer@scl.ameslab.gov>
To: Bruce Evans <bde@zeta.org.au>
cc: freebsd-current@FreeBSD.ORG
Subject: Re: Kernel backtrace for recurring page fault panic
In-Reply-To: <199810081516.BAA25214@godzilla.zeta.org.au>
Message-ID: <Pine.SGI.3.96.981009135422.5543A-100000@demios.scl.ameslab.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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?

Thanks again,
Guy

Guy Helmer, Graduate Student, Iowa State University Dept. of Computer Science 
Research Assistant, Ames Laboratory       ---         ghelmer@scl.ameslab.gov
Research Assistant, Dept. of Computer Science   ---   ghelmer@cs.iastate.edu
http://www.cs.iastate.edu/~ghelmer


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