Re: fusefs-kmod broken?

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_at_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