amd64/131209: 7.1-STABLE amd64 crash
John Baldwin
jhb at freebsd.org
Tue Feb 3 08:10:04 PST 2009
The following reply was made to PR amd64/131209; it has been noted by GNATS.
From: John Baldwin <jhb at freebsd.org>
To: Roar Pettersen <roar.pettersen at uib.no>
Cc: freebsd-amd64 at freebsd.org, freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/131209: 7.1-STABLE amd64 crash
Date: Tue, 3 Feb 2009 10:20:32 -0500
On Tuesday 03 February 2009 2:34:04 am Roar Pettersen wrote:
> Hello John !
>
> > Is your source tree out of date wrt your kernel? The kernel messages
clearly
> > show a page fault, not a TSS fault as Xtss() would indicate. Also, if
> > vattr_null() was passed a NULL pointer, it should have faulted at the
start
> > of its routine rather than halfway through it.
>
> Yes, forgot that I had done a buildworld and build kernel to get all new
> patches installed.
>
>
> No crash yet, but each time we do a "shutdown -r now" because the system
> get unstable/unusable after some hours (4-6), we now get a dump each time
> :
>
> # kgdb kernel.debug /var/crash/vmcore.6
> 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 "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> <118>Feb 3 07:27:50 proxy-gw syslogd: exiting on signal 15
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> WaitSiynncing dgi s(kmsa,x v6n0o dseesc ornedmsa)i nfionrg .s.y.st6e m
> process `syncer' to stop...5 1 2 2 1 1 0 0 0 done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> All buffers synced.
> Uptime: 7h8m11s
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x10
> fault code = supervisor read data, page not present
> instruction pointer = 0x8:0xffffffff8021d746
> stack pointer = 0x10:0xfffffffef7cf3b20
> frame pointer = 0x10:0x12000
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 29 (irq257: bce1)
> trap number = 12
> panic: page fault
> cpuid = 1
> Uptime: 7h8m11s
> Physical memory: 4087 MB
> Dumping 362 MB: 347 331 315 299 283 267 251 235 219 203 187 171 155 139
> 123 107 91 75 59 43 27 11
>
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb)
> (kgdb) backtrace
> #0 doadump () at pcpu.h:195
> #1 0x0000000000000004 in ?? ()
> #2 0xffffffff802fae39 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:418
> #3 0xffffffff802fb242 in panic (fmt=0x104 <Address 0x104 out of bounds>)
> at /usr/src/sys/kern/kern_shutdown.c:574
> #4 0xffffffff804fbd63 in trap_fatal (frame=0xffffff0001559000,
> eva=Variable "eva" is not available.
> ) at /usr/src/sys/amd64/amd64/trap.c:764
> #5 0xffffffff804fc135 in trap_pfault (frame=0xfffffffef7cf3a70,
> usermode=0)
> at /usr/src/sys/amd64/amd64/trap.c:680
> #6 0xffffffff804fca78 in trap (frame=0xfffffffef7cf3a70) at
> /usr/src/sys/amd64/amd64/trap.c:449
> #7 0xffffffff804e24be in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:209
> #8 0xffffffff8021d746 in bce_intr (xsc=Variable "xsc" is not available.
> ) at /usr/src/sys/dev/bce/if_bce.c:5748
Looks to be a bug here. Can you do 'frame 8' followed by 'l' in kgdb?
--
John Baldwin
More information about the freebsd-amd64
mailing list