Re: -CURRENT spontaneously rebooting when using X

On Monday 23 January 2006 09:13, Chris Hedley wrote:
> On Mon, 23 Jan 2006, Chris Hedley wrote:
> > Could someone advise how I can get a bit more information to report?  :)
> >
> > I've just installed a fresh 6.0-RELEASE and immediately upgraded it to
> > -CURRENT (most recent yesterday evening) and installed the latest xorg
> > servers.  When I start X, usually within a few seconds to a couple of
> > minutes the system falls over, but unfortauntely it doesn't leave me at
> > the kernel debugger and doesn't do a kernel dump for some reason or
> > other, it just goes
>
>  	...
>
> Thanks to David Wolfskill for talking me through setting up a serial
> console, I'm able to extract some debugging information from my system
> now.  Some initial bits (retyped by me, hopefully not too many mistakes)
> follow:
>
> kernel trap 12 with interrupts disabled
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x48
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xffffffff802b14fa
> stack pointer           = 0x10:0xffffffffa263b9d0
> frame pointer           = 0x10:0xffffffffa263ba10
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 38 (syncer)
> [thread pid 38 tid 100042 ]
> Stopped at       propagate_priority+0x6a     movq       0x48(%r15),%rbx
>
> Tracing pid 38 tid 100042 td 0xffffff003db4a000
> propagate_priority() at propagate_priority+0x6a
> turnstile_wait() at turnstile_wait+0x20e
> _mtx_lock_sleep() at _mtx_lock_sleep+0x89
> vfs_busy_pages() at vfs_busy_pages+0xd4
> bufwrite() at burwrite+0x7b
> vfs_bio_awrite() at vfs_bio_awrite+0x5a
> vop_stdfsync() at vop_stdfsync+0x28c
> VOP_FSYNC_APV() at VOP_FSYNC+APV+0x3d
> sched_sync() at sched_sync+0x415
> fork_exit() at fork_exit+0x86
> form_trampoline() at fork_trampoline+0xe
> --- trap 0, rip = 0, rsp = 0xffffffffa263bd40, rbp = 0 ---
>
> Is there anything else that might be useful in tracking down this problem?
> If it's anything that's very involved I may need to be pointed at an
> instruction manual!

It's a bug, but you can try this workaround:

Index: kern/subr_turnstile.c
===================================================================
RCS file: /usr/cvs/src/sys/kern/subr_turnstile.c,v
retrieving revision 1.155
diff -u -r1.155 subr_turnstile.c
--- kern/subr_turnstile.c	17 Jan 2006 16:47:42 -0000	1.155
+++ kern/subr_turnstile.c	23 Jan 2006 21:23:42 -0000
_at__at_ -228,6 +228,13 _at__at_
 		    ts->ts_lockobj->lo_name));
 
 		/*
+		 * Add a safety net for production kernels (non-INVARIANTS).
+		 * If the thread isn't blocked on a lock, just bail.
+		 */
+		if (!TD_ON_LOCK(td))
+			return;
+
+		/*
 		 * Pick up the lock that td is blocked on.
 		 */
 		ts = td->td_blocked;

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org