From owner-freebsd-alpha Thu Jun 7 11:18:50 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 118B837B401; Thu, 7 Jun 2001 11:18:46 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA20256; Thu, 7 Jun 2001 14:18:45 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.3/8.9.1) id f57IIFV54264; Thu, 7 Jun 2001 14:18:15 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15135.50535.462934.648630@grasshopper.cs.duke.edu> Date: Thu, 7 Jun 2001 14:18:15 -0400 (EDT) To: John Baldwin Cc: freebsd-alpha@FreeBSD.org Subject: Re: Possible VM patch.. In-Reply-To: References: <15134.49536.206316.481220@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Baldwin writes: > > > I just got a panic on my UP machine. This one is a very weird panic that is > only triggered when the witness code gets its internal per-process lock lists > out of sync. I wish it was easier to trigger. It may be a witness bug or it > may be some sort of data corruption. :( The NULL vm_object panic in > vm_fault1() that I'm getting on the dual Rawhide seems fairly reproducible, so > I've added in a bunch of KTR tracepoints to see if I can narrow it down. Here's my latest panic: login: panic: mutex vm not owned at ../../vm/vm_page.c:1017 cpuid = 0; panic Stopped at Debugger+0x34: zapnot v0,#0xf,a0 db> tr Debugger() at Debugger+0x34 panic() at panic+0x178 _mtx_assert() at _mtx_assert+0x64 vm_page_free_toq() at vm_page_free_toq+0x38 vm_page_alloc() at vm_page_alloc+0x270 vm_fault1() at vm_fault1+0x648 vm_fault() at vm_fault+0x204 trap() at trap+0xe20 XentMM() at XentMM+0x2c --- memory management fault (from ipl 0) --- --- user mode --- [I'm running an updated db_trace.c merged from NetBSD with Ross Harvey's all-singing / all dancing stack trace code, but it isn't too terribly interesting for this particular case.] db> show locks exclusive (sleep mutex) vm (0xfffffc0000815430) locked @ ../../vm/vm_fault.c:301 exclusive (sleep mutex) Giant (0xfffffc00008160c8) locked @ ../../vm/vm_fault.c:213 db> show pcpu cpuid = 0 ipis = 0 next ASN = 240 curproc = 0xfffffe00068a1480: pid 41334 "ld" curpcb = 0x7a96000 fpcurproc = none idleproc = 0xfffffe0005887600: pid 10 "idle: cpu0" spin locks held: db> x vm_mtx,10 vm_mtx: 760c20 fffffc00 730700 fffffc00 30000 vm_mtx+0x14: 0 806528 fffffc00 7b7910 vm_mtx+0x24: fffffc00 4 0 0 vm_mtx+0x34: 0 0 0 I think this is the same "can't happen" thing you were talking about earlier. We've got a panic because vm isn't owned, but wait! It is! Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message