Re: deadc0de panic in unmount()

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Sat, 25 Dec 2004 16:31:05 -0800
On Sun, Dec 26, 2004 at 10:57:21AM +1030, Greg 'groggy' Lehey wrote:
> On Saturday, 25 December 2004 at 16:22:34 -0800, Kris Kennaway wrote:
> > On Sun, Dec 26, 2004 at 10:45:50AM +1030, Greg 'groggy' Lehey wrote:
> >> On Saturday, 25 December 2004 at 15:42:36 -0800, Kris Kennaway wrote:
> >>> -current from a few days ago.  It was probably unmounting a nullfs,
> >>> devfs or linprocfs.
> >>>
> >>> panic(c06f100c,63676b70,c06efede,e4,c06f4bb5) at panic+0xac
> >>> _mtx_lock_spin(deadc0de,0,c06efede,e4,c06f9e60) at _mtx_lock_spin
> >>> lockmgr(c59df420,10007,c077c480,ca6e1000,379) at lockmgr+0x132
> >>> dounmount(c59df400,8080000,ca6e1000,379,734ff58) at dounmount+0xa5
> >>> unmount(ca6e1000,f13a6d14,8,e,2) at unmount+0x1f4
> >>> syscall(2f,2f,2f,82ff704,8573911) at syscall+0x13b
> >>> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> >>> --- syscall (22, FreeBSD ELF32, unmount), eip = 0x82a21df, esp = 0xbfbfe0ac, ebp = 0xbfbfe168 ---
> >>
> >> Do you have a dump?
> >
> > No, dumping is broken for me on this and some other machines (it
> > starts with 'Dumping 2047 MB' but immediately returns).
> 
> Does this happen if you do 'call doadump' as well?

Yeah, that's how I always try and dump since I learned that relying on
the kernel to try and dump itself was .. not reliable.

Kris

Received on Sat Dec 25 2004 - 23:31:27 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:25 UTC