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