Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033

[Willem Jan Withagen]

Well the Tyan board is finally in. Look like a quality PCB, althoug some of the
connectors are somewhat far away for the large case I'm using..
First need to do some paid work, but then I'll start rebuilding the system.

I guess we'll know more by tomorrow. :)

--WjW


----- Original Message ----- 
From: "John Baldwin" <jhb at FreeBSD.org>
To: "Robert Watson" <rwatson at FreeBSD.org>
Cc: "Willem Jan Withagen" <wjw at withagen.nl>; <current at FreeBSD.org>;
<bzeeb+freebsd+lor at zabbadoz.net>; <alc at FreeBSD.org>
Sent: Wednesday, July 28, 2004 5:18 AM
Subject: Re: Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033


> On Tuesday 27 July 2004 06:51 pm, Robert Watson wrote:
> > On Wed, 28 Jul 2004, Willem Jan Withagen wrote:
> > > Running on amd64:
> >
> > <snip>
> > <unsnip>
> >
> > > And right followed by....
> > >
> > > panic: lock (sleep mutex) Giant not locked @
> > > /home2/src/sys/kern/vfs_syscalls.c: 959
> > > cpuid = 0;
> > > KDB: stack backtrace:
> > > kdb_backtrace() at kdb_backtrace+0x34
> > > panic() at panic+0x1d2
> > > witness_unlock() at witness_unlock+0xdd
> > > _mtx_unlock_flags() at _mtx_unlock_flags+0x68
> > > kern_open() at kern_open+0x128
> > > open() at open+0x18
> > > syscall() at syscall+0x330
> > > Xfast_syscall() at Xfast_syscall+0xa8
> > > --- syscall (5, FreeBSD ELF64, open), rip = 0x76d75c, rsp =
> > > 0x7fffffffe088, rbp = 0x7fffffffe0c0 ---
> > > KDB: enter: panic
> > > [thread 100316]
> > > Stopped at      kdb_enter+0x2e: nop
> >
> > I've seen several reports of "mysterious" panics where Giant isn't held on
> > return from namei() or other points following a name lookup.  Kris
> > Kenneway reported this on the package build cluster, for example.  I'm
> > wondering if something handling a page fault hit by namei() during a
> > string copy in from user space if resulting in Giant not being held where
> > it should be.  In Kris's case, we tried pushing around GIANT_REQUIRED some
> > because I thought maybe the caller wasn't holding Giant when it should,
> > but that turned out not to be it.  So maybe we have some sort of
> > preemption/VM/locking issue?
>
> The preemption case is very easy to test, just turn it off in machine/param.h
> and see if it goes away.
>
> -- 
> John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
>
>