From owner-freebsd-current Tue Feb 6 18:35: 2 2001 Delivered-To: freebsd-current@freebsd.org Received: from jbloom.jbloom.org (reyim.ne.mediaone.net [24.218.251.241]) by hub.freebsd.org (Postfix) with ESMTP id 8313137B401; Tue, 6 Feb 2001 18:34:43 -0800 (PST) Received: from acm.org (localhost [127.0.0.1]) by jbloom.jbloom.org (8.11.2/8.11.2) with ESMTP id f172Yf071651; Tue, 6 Feb 2001 21:34:42 -0500 (EST) (envelope-from bloom@acm.org) Message-ID: <3A80B43B.659DCED5@acm.org> Date: Tue, 06 Feb 2001 21:34:35 -0500 From: Jim Bloom Reply-To: bloom@acm.org X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 5.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: current@FreeBSD.org Subject: Re: Kernel Panic from Yesterday's CVSup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Baldwin wrote: > > On 06-Feb-01 Jim Bloom wrote: > > Which kernel do you want me to try this with? I have tried two > > different kernels with two different errors. (Both have been sent at > > different times in the past couple days.) The registers listed here > > from the second kernel (with WITNESS, INVARIANTS, INVARIANT_SUPPORT, > > MUTEX_DEBUG). As such the addresses disagree (sw1b has 8 more bytes for > > invariants), but the text segment was correct. > > You'll have to turn off WITNESS to get it to die in cpu_switch(), but you'll > want to leave the others on for now. I turned off WITNESS and still received the mutex error. A little reading of the code showed that mutex assertions are inclued with ifdef INVARIANTS. > > > Without debug, I get the trap 9. With debug, I get a trap 12 > > immediately followed by a panic with mutex shced lock recursion. > > > > I rebuilt the kernel with out the debugging and check the state of > > things. The code is correct and the esi register had the expected > > value. > > Hmmmmmmmm. Ok, try with debugging minus WITNESS (and you don't want > MUTEX_DEBUG, that slows things down a _lot_). Then see if %esi is > still 0x100 instead of 0x20. If so, then check the instructions to make sure > they aren't hosed. With INVARIANTS turned off and WITNESS on, I received a trap 27 (stack fault) at sw1b+0x77. The instructions are fine and %esi was 0x20 as it should be. I won't worry about MUTEX_DEBUG being slow just yet. I am only around the start of /etc/rc when the machine dies. Do you have any other ideas on things that I can try to diagnose this problem? Jim Bloom bloom@acm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message