Re: Fatal trap 12: page fault while in kernel mode (subr_turnstile.c:226)

From: Jonathan Noack <noackjr_at_alumni.rice.edu>
Date: Wed, 18 May 2005 17:20:26 -0500
On 05/18/05 17:03, Doug White wrote:
> On Mon, 16 May 2005, Jonathan Noack wrote:
>>I was in X so no dump or ddb.
> 
> You have INVARIANTS compiled in?

Sure do, along with WITNESS, WITNESS_SKIPSPIN, KDB, KDB_TRACE, and DDB. 
  Why do you ask?

I remember reading somewhere that at this point a panic in X results in 
an instant reboot.  This has certainly been my experience.  I assume 
this is a difficult problem or it would have been fixed long ago. 
Anyone know why this happens?

>>Fatal trap 12: page fault while in kernel mode
>>fault virtual address	= 0x4
>>fault code		= supervisor read, page not present
>>instruction pointer	= 0x20:0xc051c117
>>stack pointer	        = 0x28:0xf976c8a8
>>frame pointer	        = 0x28:0xf976c8cc
>>code segment		= base 0x0, limit 0xfffff, type 0x1b
>>			= DPL 0, pres 1, def32 1, gran 1
>>processor eflags	= resume, IOPL = 0
>>current process		= 939 (firefox-bin)
>>trap number		= 12
>>panic: page fault
>>KDB: stack backtrace:
>>panic(c06a83b3,c06d27e7,f976c868,1,1) at panic+0x13a
>>trap_fatal(c06d2aff,c,2,118,4) at trap_fatal+0x255
>>trap(b23c0008,28,c2ed0028,c29a07c0,c3168900) at trap+0x221
>>calltrap() at calltrap+0x5
>>--- trap 0xc, eip = 0xc051c117, esp = 0xf976c8a8, ebp = 0xf976c8cc ---
>>propagate_priority(c07127c0,8,c06ba676,254,c0717134) at
>>propagate_priority+0x197
>>turnstile_wait(c3164668,c2ed9a80,c06b6aff,216,c3164668) at
>>turnstile_wait+0x1f7
>>_mtx_lock_sleep(c3164668,c3168900,0,c06b79b9,27e) at _mtx_lock_sleep+0x9c
>>_mtx_lock_flags(c3164668,0,c06b79b9,27e,f976c9e4) at _mtx_lock_flags+0xaf
>>kern_sigprocmask(c3168900,3,f976c9e4,0,0) at kern_sigprocmask+0x37
>>nfs_restore_sigmask(c3168900,f976c9e4,6,c3168900,c2f8a980) at
>>nfs_restore_sigmask+0x34
>>nfs_readrpc(c332b660,f976ca4c,c2f8a980,c2f4c294,cf1) at nfs_readrpc+0x104
>>nfs_doio(c332b660,d64cad80,c2f8a980,c3168900,f976cab8) at nfs_doio+0x55f
>>nfs_write(f976cbfc,0,f976cc74) at nfs_write+0x7e1
>>VOP_WRITE_APV(c06f9ca0,f976cbfc,c3168900,21b,7f) at VOP_WRITE_APV+0x69
>>vn_write(c30bd288,f976cc74,c2f8a980,0,c3168900) at vn_write+0x1ae
>>dofilewrite(1b,a3b7060,1fff,ffffffff,ffffffff) at dofilewrite+0xac
>>write(c3168900,f976cd04,c,1,3) at write+0x77
>>syscall(3b,ffff003b,bf8f003b,8067000,8fd5) at syscall+0x13b
>>Xint0x80_syscall() at Xint0x80_syscall+0x1f
>>--- syscall (4, FreeBSD ELF32, write), eip = 0x28797a63, esp =
>>0xbfbfdb5c, ebp = 0xbfbfdb78 ---
>>
>>$ addr2line -e kernel.debug 0xc051c117
>>/usr/src/sys/kern/subr_turnstile.c:226
>>
>>223:		/*
>>224:		 * If we aren't blocked on a lock, we should be.
>>225:		 */
>>226:		KASSERT(TD_ON_LOCK(td), (
>>227:		    "thread %d(%s):%d holds %s but isn't blocked on a lock\n",
>>228:		    td->td_tid, td->td_proc->p_comm, td->td_state,
>>229:		    ts->ts_lockobj->lo_name));

-- 
Jonathan Noack | noackjr_at_alumni.rice.edu | OpenPGP: 0x991D8195

Received on Wed May 18 2005 - 20:20:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC