From owner-freebsd-current@FreeBSD.ORG Mon Aug 23 12:40:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 745F010656AD for ; Mon, 23 Aug 2010 12:40:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABEB8FC0C for ; Mon, 23 Aug 2010 12:40:34 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A954646B2C; Mon, 23 Aug 2010 08:40:33 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 223038A04F; Mon, 23 Aug 2010 08:40:32 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Aug 2010 08:26:49 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201008230826.49509.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Aug 2010 08:40:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ian FREISLICH Subject: Re: fusefs-kmod broken? 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 Aug 2010 12:40:34 -0000 On Friday, August 20, 2010 12:11:00 pm Ian FREISLICH wrote: > Hi > > I have a system that relies on Fuse and OWFS to manage the power > at my house. I get the following panic when writing to to one of > the PIO devices: > > The panic isn't really helpful because it looks like the stack frame > has been broken. > > Have others seen this? I've tried rebuilding everything from a > clean slate but it doesn't help. The machine used to be -STABLE, > which worked until 21 April 2010, but no kernel since has worked. > > brane.freislich.nom.za dumped core - see /var/crash/vmcore.7 > > Fri Aug 20 16:07:17 SAST 2010 > > FreeBSD brane.freislich.nom.za 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Fri Aug 20 13:53:55 SAST 2010 ianf@brane.freislich.nom.za:/usr/obj/usr/src/sys/BRANE i386 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xe75d3b50 > frame pointer = 0x28:0xe75d3c14 > 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 = 56578 (sh) > trap number = 12 > panic: page fault > KDB: stack backtrace: > db_trace_self_wrapper(c07b0ffc,e75d39e8,c05b4aff,c07af087,c0838240,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(c07af087,c0838240,c079b1a4,e75d39f4,e75d39f4,...) at kdb_backtrace+0x29 > panic(c079b1a4,c07c9e3f,c784aca0,1,1,...) at panic+0xaf > trap_fatal(c783e000,0,1,0,c782c8c0,...) at trap_fatal+0x353 > trap_pfault(c274a3a8,0,c669eaa0,c784ab00,c7845000,...) at trap_pfault+0x25b > trap(e75d3b10) at trap+0x423 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0, esp = 0xe75d3b50, ebp = 0xe75d3c14 --- > uart_z8530_class(c784ab00,ffffff9c,284052c4,0,402,...) at 0 > kern_open(c784ab00,284052c4,0,601,1b6,...) at kern_open+0x35 > open(c784ab00,e75d3cec,e75d3d28,e75d3d28,e75d3c02,...) at open+0x30 > syscallenter(c784ab00,e75d3ce4,e75d3ce4,0,c784ab00,...) at syscallenter+0x343 > syscall(e75d3d28) at syscall+0x34 > Xint0x80_syscall() at Xint0x80_syscall+0x21 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281e579b, esp = 0xbfbfe96c, ebp = 0xbfbfea28 --- > Uptime: 1h49m31s > Physical memory: 2007 MB > Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 The uart thing is a red herring, notice the actual PC value is '0'. Something in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in kgdb would be a good start of where to look. -- John Baldwin