Date: Thu, 7 Jun 2001 14:18:15 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-alpha@FreeBSD.org Subject: Re: Possible VM patch.. Message-ID: <15135.50535.462934.648630@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.010606170002.jhb@FreeBSD.org> References: <15134.49536.206316.481220@grasshopper.cs.duke.edu> <XFMail.010606170002.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <v0=0x0,a0=0x6> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15135.50535.462934.648630>