From owner-freebsd-net  Fri May 24 11:15: 8 2002
Delivered-To: freebsd-net@freebsd.org
Received: from InterJet.dellroad.org (adsl-63-194-81-26.dsl.snfc21.pacbell.net [63.194.81.26])
	by hub.freebsd.org (Postfix) with ESMTP
	id 32B5737B403; Fri, 24 May 2002 11:15:03 -0700 (PDT)
Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.1.1.20])
	by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id LAA03358;
	Fri, 24 May 2002 11:07:57 -0700 (PDT)
Received: (from archie@localhost)
	by arch20m.dellroad.org (8.11.6/8.11.6) id g4OI7Ja70244;
	Fri, 24 May 2002 11:07:19 -0700 (PDT)
	(envelope-from archie)
From: Archie Cobbs <archie@dellroad.org>
Message-Id: <200205241807.g4OI7Ja70244@arch20m.dellroad.org>
Subject: splimp() during panic?
To: freebsd-net@freebsd.org
Date: Fri, 24 May 2002 11:07:19 -0700 (PDT)
Cc: freebsd-hackers@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL88 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-net.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-net>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-net>
X-Loop: FreeBSD.org

Hi,

I'm trying to debug a mbuf corruption bug in the kernel. I've added
an mbuf sanity check routine which calls panic() if anything is amiss
with the mbuf free list, etc. This function runs at splimp() and if/when
it calls panic() the cpl is still at splimp().

My question is: does this guarantee that the mbuf free lists, etc. will
not be modified between the time panic() is called and the time a core
file is generated? For example, if an incoming packet causes a networking
interrupt after panic() has been called but before the core file is
written, will that interrupt be blocked when it calls splimp()?

I've been working under this assumption but it seems to not be
valid, because I seem to be seeing panics for situations that are
not true in the core file.

If this is not a valid assumption, is there an easy way to 'freeze'
the mbuf free lists long enough to generate the core file when an
inconsistency is found (other than adding the obvious hack)?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

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