Date: Wed, 10 Mar 1999 09:35:39 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: Thierry.Besancon@lps.ens.fr, dwhite@gdi.uoregon.edu, freebsd-smp@FreeBSD.ORG Cc: Pierre.David@prism.uvsq.fr, alc@cs.rice.edu, besancon@lps.ens.fr, dillon@apollo.backplane.com, jt@ratp.fr Subject: Re: lockmgr() panic Message-ID: <199903101435.JAA11204@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> I have in production a ASUS P2B machine with dual 350 MHz PII
> (with Intel 440BX chip ?) and 512 Mb of ram.
> It runs FreeBSD 3.1
>
> It paniced last week so I compiled in DDB in order to have more
> information. Today it paniced again, with the following messages :
>
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 010000002; cpuid = 1; lapic.id = 00000000
> fault virtual address = 0xb8
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf01430a7
> stack pointer = 0x10:0xff804eb4
> frame pointer = 0x10:0xff804ec8
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = Idle
> interrupt mask = net tty bio cam <- SMP : XXX
> kernel: type 12 trap, code=0
> Stopped at tsleep+0x1b: movl 0xb8(%ebx),%eax
>
> The "trace" command gave :
>
> db> trace
> tsleep(f027bab4,4,f023b455,0,f027bab4) at tsleep+0x1b
> acquire(f027bab4,1000000,600,f027bab4,c6040000) at acquire+0x91
> lockmgr(f027bab4,2,0,0,1) at lockmgr+0x260
> kmem_malloc(f027bab4,1000,1,f113f300,ff804f88) at kmem_malloc+0x51
> m_clalloc(1,1) ar m_clalloc+0x2e
> fxp_add_rfabuf(f1762e00,f11e9980) at fxp_add_rfabuf+0xa5
> fxp_intr(f1762e00,0,f0250010,10,0) at fxp_intr+0xe1
> Xresume18() at Xresume18+0x51
> --- interrupt, eip = 0xf020dfe0, esp = 0xff804ff0, ebp = 0 ---
> default_halt() at default_halt
>
kmem_malloc() blocked when trying to lock the mbuf map, in an interrupt
context, even though M_NOWAIT was set. We need a non-blocking version of
vm_map_lock() [vm_map_lock_try()?] in this situation. I'm forwarding this
to Alan Cox and Matt Dillon...
> While typing this mail, my machine paniced again with a more explicit message ?
>
> panic: lockmgr: locking against myself
> mp_lock = 010000003 ; cpuid = 1; lapic.id = 00000000
> Debugger("panic")
> Stopped at Debugger+0x37: movl $0,in_Debugger
>
> db> trace
> Debugger(f0230f52) at Debugger+0x37
> panic() at panic+0xa4
> lockmgr() at lockmgr+0x228
> vm_map_growstack() at vm_map_growstack+0x29
> grow_stack() at grow_stack+0xe
> trap_pfault() at trap+0x33e
> calltap() at calltrap+0x3c
> --- trap 0xc, eip = 0xf020c3a3, esp = 0xfa7f6d6c, ebp = 0xfa7f6d84 ---
> pmap_enter() at pmap_enter+0xa7
> vm_fault() at vm_fault+0x83a
> trap_pfault() at trap_pfault+0xc4
> trap() at trap+0x33e
> calltrap() at calltrap+0x3c
> --- trap 0xc, eip = ..., esp = ..., ebp = ... ---
> zalloci() at zalloci+0x33
> vm_map_entry_create() at vm_map_entry_create+0x27
> _vm_map_clip_end() at _vm_map_clip_end+0x42
> vm_map_madvise() at vm_map_madvise+0xc9
> madvise() at madvise+0x47
> syscall(27,27,2c,2811c000,efbfb9ec) at syscall+0x187
> Xint0x80_syscall() at Xint0x80_syscall+0x4c
>
This is a completely different problem. It looks like a page fault on
a kernel page table page, which should have been wired down. Could you
provide more detail, e.g. fault address for both traps?
>
> So, does anybody have an idea about why my problem occurs ?
>
> Any fix ?
>
> Thanks in advance.
> A special thanks for all the people that made FreeBSD runnable on SMP.
>
> Thierry
-lq
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903101435.JAA11204>