Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 May 2005 02:45:16 -0700
From:      Jaye Mathisen <mrcpu@mathisen.org>
To:        hackers@freebsd.org
Subject:   Panic with 5.4 -- kgdb output included
Message-ID:  <20050529094516.GT57649@main.mathisen.org>

next in thread | raw e-mail | index | archive | help


5.4-STABLE from 5/27, repeated panics.  Finally got a crashdump, fired up kgdb and:
(is there any advantage to booting the kernel.debug instead of the regular kernel?  Can't think
of one, but possibley...).

The box does run several jails.  It has been crashing regularly under both 5.3-RELEASE and now 5.4-STABLE.

Apps are all mysql/apache/mail apps, nothing fancy.

Disk controller is an adaptec using the asr0 driver, and it is a dual Xeon compiled with SMP suppo0rt.


s1# kgdb kernel.debug /home/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 "i386-marcel-freebsd".
#0  doadump () at pcpu.h:160
160             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) where
#0  doadump () at pcpu.h:160
#1  0xc051dfdb in boot (howto=260) at ../../../kern/kern_shutdown.c:410
#2  0xc051e301 in panic (fmt=0xc06b997e "%s") at ../../../kern/kern_shutdown.c:566
#3  0xc06937f0 in trap_fatal (frame=0xe9194968, eva=1109191441) at ../../../i386/i386/trap.c:817
#4  0xc0693533 in trap_pfault (frame=0xe9194968, usermode=0, eva=1109191441)
    at ../../../i386/i386/trap.c:735
#5  0xc069316d in trap (frame=
      {tf_fs = -1068433384, tf_es = -384237552, tf_ds = 16777232, tf_edi = -1002848656, tf_esi = 1109191437, tf_ebp = -384218704, tf_isp = -384218732, tf_ebx = -1023663500, tf_edx = 1109191437, tf_ecx = -1066185404, tf_eax = 0, tf_trapno = 12, tf_err = 2, tf_eip = -1068237450, tf_cs = 8, tf_eflags = 66050, tf_esp = -1023663616, tf_ss = -1026971648}) at ../../../i386/i386/trap.c:425
#6  0xc0680c7a in calltrap () at ../../../i386/i386/exception.s:140
#7  0xc0510018 in linker_find_file_by_name (filename=0xc439be70 "|¸pĀ\223\023mĀ\223\023mĀ")
    at ../../../kern/kern_linker.c:419
#8  0xc053fcca in selwakeuppri (sip=0xc2fc2274, pri=89) at ../../../kern/sys_generic.c:1081
#9  0xc054cb31 in ttwakeup (tp=0x10202) at ../../../kern/tty.c:2370
#10 0xc054b7d8 in ttymodem (tp=0xc2fc2200, flag=0) at ../../../kern/tty.c:1629
#11 0xc054f4c3 in ptcopen (dev=0xc2c9a800, flag=3, devtype=8192, td=0x0) at linedisc.h:136
#12 0xc04e220e in spec_open (ap=0xe9194a70) at ../../../fs/specfs/spec_vnops.c:207
#13 0xc04e1f53 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:118
#14 0xc057d361 in vn_open_cred (ndp=0xe9194bd4, flagp=0xe9194cd4, cmode=0, cred=0xc67ed300, fdidx=0)
    at vnode_if.h:228
#15 0xc057cf46 in vn_open (ndp=0x0, flagp=0xe9194cd4, cmode=0, fdidx=6) at ../../../kern/vfs_vnops.c:91
#16 0xc0576ec3 in kern_open (td=0xc22adc00, path=0x0, pathseg=UIO_USERSPACE, flags=3, mode=0)
    at ../../../kern/vfs_syscalls.c:937
#17 0xc0576dd4 in open (td=0xc22adc00, uap=0x0) at ../../../kern/vfs_syscalls.c:906
#18 0xc0693b2b in syscall (frame=
      {tf_fs = 47, tf_es = 134676527, tf_ds = -1078001617, tf_edi = -1, tf_esi = 671951917, tf_ebp = -1077943224, tf_isp = -384217756, tf_ebx = 671959136, tf_edx = 671951934, tf_ecx = 674500524, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = 674003695, tf_cs = 31, tf_eflags = 662, tf_esp = -1077943316, tf_ss = 47}) at ../../../i386/i386/trap.c:1009
#19 0xc0680ccf in Xint0x80_syscall () at ../../../i386/i386/exception.s:201
#20 0x0000002f in ?? ()
#21 0x0807002f in ?? ()
#22 0xbfbf002f in ?? ()
#23 0xffffffff in ?? ()
#24 0x280d2c2d in ?? ()
#25 0xbfbfe448 in ?? ()
#26 0xe9194d64 in ?? ()
#27 0x280d4860 in ?? ()
#28 0x280d2c3e in ?? ()
#29 0x28340fac in ?? ()
#30 0x00000005 in ?? ()
#31 0x0000000c in ?? ()
#32 0x00000002 in ?? ()
#33 0x282c7aef in ?? ()
#34 0x0000001f in ?? ()
#35 0x00000296 in ?? ()
#36 0xbfbfe3ec in ?? ()
#37 0x0000002f in ?? ()
#38 0x00000000 in ?? ()
#39 0x00000000 in ?? ()
#40 0x00000000 in ?? ()
#41 0x00000000 in ?? ()
#42 0x2afb4000 in ?? ()
#43 0xc22aca98 in ?? ()
#44 0xc22adc00 in ?? ()
#45 0xe9194828 in ?? ()
#46 0xe9194810 in ?? ()
---Type <return> to continue, or q <return> to quit---
#47 0xc1e9a480 in ?? ()
#48 0xc052e657 in sched_switch (td=0x280d2c2d, newtd=0x280d4860, flags=Cannot access memory at address 0xbfbfe458
)
    at ../../../kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050529094516.GT57649>