Panic with 5.4 -- kgdb output included
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 0x002f in ?? ()
#21 0x0807002f in ?? ()
#22 0xbfbf002f in ?? ()
#23 0x in ?? ()
#24 0x280d2c2d in ?? ()
#25 0xbfbfe448 in ?? ()
#26 0xe9194d64 in ?? ()
#27 0x280d4860 in ?? ()
#28 0x280d2c3e in ?? ()
#29 0x28340fac in ?? ()
#30 0x0005 in ?? ()
#31 0x000c in ?? ()
#32 0x0002 in ?? ()
#33 0x282c7aef in ?? ()
#34 0x001f in ?? ()
#35 0x0296 in ?? ()
#36 0xbfbfe3ec in ?? ()
#37 0x002f in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x 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?)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with 5.4 -- kgdb output included
On Sun, May 29, 2005 at 02:45:16AM -0700, Jaye Mathisen wrote:
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...).
Unfortunately this is a known bug. Doug White was looking at it, so
you should talk to him to see if you can provide anything further that
he needs.
Kris
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 0x002f in ?? ()
#21 0x0807002f in ?? ()
#22 0xbfbf002f in ?? ()
#23 0x in ?? ()
#24 0x280d2c2d in ?? ()
#25 0xbfbfe448 in ?? ()
#26 0xe9194d64 in ?? ()
#27 0x280d4860 in ?? ()
#28 0x280d2c3e in ?? ()
#29 0x28340fac in ?? ()
#30 0x0005 in ?? ()
#31 0x000c in ?? ()
#32 0x0002 in ?? ()
#33 0x282c7aef in ?? ()
#34 0x001f in ?? ()
#35 0x0296 in ?? ()
#36 0xbfbfe3ec in ?? ()
#37 0x002f in ?? ()
#38 0x in ?? ()
#39 0x in ?? ()
#40 0x in ?? ()
#41 0x 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?)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
