-CURRENT spontaneously rebooting when using X
John Baldwin
jhb at freebsd.org
Mon Jan 23 13:23:47 PST 2006
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
@@ -228,6 +228,13 @@
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
More information about the freebsd-current
mailing list