> > I don't think that this dump is useful for debugging this problem. Perhaps,
> > if
> > you compile the kernel with DEBUG_LOCKS, you will get more useful info.
>
> I checked through the source for DEBUG_LOCKS, it doesn't appear to do anything
> other than to printout information informati
On May 27, 10:32am, "David E. Cross" wrote:
} Subject: Re: kernel debugging assistance
} > I don't think that this dump is useful for debugging this problem. Perhaps,
if
} > you compile the kernel with DEBUG_LOCKS, you will get more useful info.
} >
} > Dima
}
} I
> I don't think that this dump is useful for debugging this problem. Perhaps,
> if
> you compile the kernel with DEBUG_LOCKS, you will get more useful info.
>
> Dima
I checked through the source for DEBUG_LOCKS, it doesn't appear to do anything
other than to printout information information
> I am trying to trace down the cause of the recursive lock and I stumbled upon
> this:
>
> (kgdb) bt
> #0 boot (howto=256) at ../../kern/kern_shutdown.c:285
> #1 0xc014b3f4 in at_shutdown (
> function=0xc0234aca
> <__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+154>, arg=0x10002,
> qu
I am trying to trace down the cause of the recursive lock and I stumbled upon
this:
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014b3f4 in at_shutdown (
function=0xc0234aca
<__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+154>, arg=0x10002,
queue=-951064448) at
5 matches
Mail list logo