Re: semi-interesting panic when rebooting

On Wednesday 08 February 2006 13:15, Matthew Jacob wrote:
> I was debugging some stuff with mpt on an HTT i386 with ~today's source
> (modified with mpt changes and a MAXPHYS/DFLTPHYS cranked up to 1m/.5m)
>
> I had a gstriped volume set that was having some, uh, issues, so I
> rebooted the system. While rebooting, it panic'd in VFS.
>
> Just reporting things in case anyone has thoughts on this one.
>
> Feb  8 10:06:16 colfax reboot: rebooted by root
> Feb  8 10:06:16 colfax syslogd: exiting on signal 15
> mpt0: Request 0xc237477c Timed out.
> mpt0: Request 0xc2374598 Timed out.
> mpt0: Timedout requests already complete. Interrupts may not be
> functioning. mpt0: Request 0xc23747d4 Timed out.
> Waiting (max 60 seconds) for system process `vnlru' to stop...done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
> Waiting (max 60 seconds) for system process `syncer' to stop...
> Syncing disks, vnodes remaining...0 0 0 done
> All buffers synced.
> Mount point /home had 2 dangling refs
> mpt0: Request 0xc23747d4 Timed out.
> mpt0: Timedout requests already complete. Interrupts may not be
> functioning. mpt0: Request 0xc23747d4 Timed out.
> mpt0: Timedout requests already complete. Interrupts may not be
> functioning.
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0xdeadc0de
> fault code  = supervisor read, page not present
> instruction pointer     = 0x20:0xc06be1fc
> stack pointer         = 0x28:0xdb9d99c8
> frame pointer         = 0x28:0xdb9d99c8
> code segment  = base 0x0, limit 0xfffff, type 0x1b
>             = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 696 (lmdd)
> [thread pid 696 tid 100113 ]
> Stopped at      strlen+0x8:     cmpb    $0,0(%edx)
> db> bt
> Tracing pid 696 tid 100113 td 0xc2d0e9c0
> strlen(deadc0de,138,19,0,20d0ea54) at strlen+0x8
> kvprintf(c088646b,c0673244,db9d9aac,a,db9d9af4) at kvprintf+0x64c
> vsnprintf(c0953860,100,c088646b,db9d9af0,100) at vsnprintf+0x29
> panic(c088646b,deadc0de,c0890603,1a5,c25ac800) at panic+0xb2
> _mtx_lock_flags(c25ac83c,0,c0890603,1a5,c2ebb410) at _mtx_lock_flags+0x5a
> vfs_rel(c25ac800) at vfs_rel+0x1c
> vdestroy(c2ebb410,c2ebb410,db9d9b68,c06b0a13,c2ebb410) at vdestroy+0x202
> vdropl(c2ebb410,c2edd010,c2e5a700,c2ebb410,db9d9be4) at vdropl+0x3e
> vrele(c2ebb410) at vrele+0x167
> fdfree(c2d0e9c0) at fdfree+0x65a
> exit1(c2d0e9c0,9,db9d9c98,c2d0e9c0,c2e4c000) at exit1+0x448
> sigexit(c2d0e9c0,9,c2e4caa8,0,c088772b) at sigexit+0xdf
> postsig(9) at postsig+0x155
> ast(db9d9d38) at ast+0x35e
> doreti_ast() at doreti_ast+0x17

I bet the mutex is destroyed.  Can you do 'l *_mtx_lock_flags+0x5a' in gdb on 
your kernel.debug?

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org