From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 21:23:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4544316A420; Mon, 23 Jan 2006 21:23:47 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id A77F5445CA; Mon, 23 Jan 2006 21:23:45 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 6791610 for multiple; Mon, 23 Jan 2006 16:24:53 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k0NLNhrw003516; Mon, 23 Jan 2006 16:23:43 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Jan 2006 16:24:12 -0500 User-Agent: KMail/1.9.1 References: <20060123112629.F79825@teapot.cbhnet> <20060123140937.Q81165@teapot.cbhnet> In-Reply-To: <20060123140937.Q81165@teapot.cbhnet> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601231624.14321.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1247/Sat Jan 21 05:24:51 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: current@freebsd.org, Chris Hedley Subject: Re: -CURRENT spontaneously rebooting when using X X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 21:23:47 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org