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

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) _at_ /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 _at_
> > > /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
>
>