Date: Mon, 2 Aug 2004 13:28:59 +0200 From: "Willem Jan Withagen" <wjw@withagen.nl> To: "John Baldwin" <jhb@FreeBSD.org>, "Robert Watson" <rwatson@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Fatal LOR: PV ENTRY (UMA zone) @ /home2/src/sys/vm/uma_core.c:2033 Message-ID: <006001c47883$f20e9f70$471b3dd4@digiware.nl> References: <Pine.NEB.3.96L.1040727184919.3788J-100000@fledge.watson.org> <200407272318.46256.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> To: "Robert Watson" <rwatson@FreeBSD.org> Cc: "Willem Jan Withagen" <wjw@withagen.nl>; <current@FreeBSD.org>; <bzeeb+freebsd+lor@zabbadoz.net>; <alc@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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006001c47883$f20e9f70$471b3dd4>