Panic with 5.4 -- kgdb output included

Sun May 29 11:44:16 PDT 2005

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 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?)
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20050529/cec532ed/attachment.bin