On Tue, Nov 11, 2008 at 09:49:26AM +0100, Johan Str?m wrote:
> Hi
> One of my DL360G5 boxes running 7.0 had a panic this night:
>
> jb-2 ~$ uname -rsv
> FreeBSD 7.0-RELEASE-p4 FreeBSD 7.0-RELEASE-p4 #2: Thu Sep 4 10:49:27
> CEST 2008 johan@jb-2:/usr/obj/usr/src/sys/DL360G5
>
> The config is a GENERIC with some pf, IPSEC and ALTQ stuff enabled.
>
> jb-2 /usr/obj/usr/src/sys/DL360G5# kgdb kernel.debug /var/crash/vmcore.0
> [GDB will not be able to debug user-mode threads: /usr/lib/
> libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
> 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:
>
> panic: page fault
> cpuid = 1
> Uptime: 40d22h42m5s
> Physical memory: 10225 MB
> Dumping 867 MB: 852 836 820 804 788 772 756 740 724 708 692 676 660
> 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388
> 372 356
>
> #0 doadump () at pcpu.h:194
> 194 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
> (kgdb) where
> #0 doadump () at pcpu.h:194
> #1 0x0000000000000004 in ?? ()
> #2 0xffffffff804bb259 in boot (howto=260) at /usr/src/sys/kern/
> kern_shutdown.c:409
> #3 0xffffffff804bb65d in panic (fmt=0x104
> bounds>) at /usr/src/sys/kern/kern_shutdown.c:563
> #4 0xffffffff8079ec84 in trap_fatal (frame=0xffffff01b33229f0,
> eva=18446742984664492240) at /usr/src/sys/amd64/amd64/trap.c:724
> #5 0xffffffff8079f055 in trap_pfault (frame=0xffffffffb6337780,
> usermode=0) at /usr/src/sys/amd64/amd64/trap.c:641
> #6 0xffffffff8079f998 in trap (frame=0xffffffffb6337780) at /usr/src/
> sys/amd64/amd64/trap.c:410
> #7 0xffffffff8078560e in calltrap () at /usr/src/sys/amd64/amd64/
> exception.S:169
> #8 0xffffffff80494b0b in knlist_remove_kq (knl=0xffffff0114407748,
> kn=0xffffff0054f5fc30, knlislocked=0, kqislocked=0)
> at /usr/src/sys/kern/kern_event.c:1615
> #9 0xffffffff80495f58 in kqueue_register (kq=Variable "kq" is not
> available.
> ) at /usr/src/sys/kern/kern_event.c:956
> #10 0xffffffff804962f3 in kern_kevent (td=0xffffff01b33229f0,
> fd=Variable "fd" is not available.
> ) at /usr/src/sys/kern/kern_event.c:673
> #11 0xffffffff80496ca5 in kevent (td=0xffffff01b33229f0,
> uap=0xffffffffb6337be0) at /usr/src/sys/kern/kern_event.c:594
> #12 0xffffffff8079f2d7 in syscall (frame=0xffffffffb6337c70) at /usr/
> src/sys/amd64/amd64/trap.c:852
> #13 0xffffffff8078581b in Xfast_syscall () at /usr/src/sys/amd64/amd64/
> exception.S:290
> #14 0x0000000010999ccc in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)
>
>
> Please let me know if I can help with anything else. Is there any way
> to know which app caused this?
> I Did some googling with only one or two similar crashes as result,
> although the hits didn't give much..
> I've never had this crash before.


There is very high chances that the problem fixed in the 7.1.
Unless it is easily reproducable in your settings, there is no
easy way to confirm this.

You can do "info threads" in the kgdb to overview processes on the
crashed system. The thread that was on the CPU during the crash will
be marked by star.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkkZbGMACgkQC3+MBN1Mb4gg1ACgo3TIuNEKKA bwPoOXmKmousAy
jgYAoMGLAuCrQh1uf/E+WoXqWSrdUIZ/
=XpRM
-----END PGP SIGNATURE-----