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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
pgp3ShzYSiavH.pgp
Description: PGP signature
