On Sat, Dec 30, 2000 at 12:23:58PM -0800, John Baldwin wrote:
>
> On 30-Dec-00 Szilveszter Adam wrote:
> > On Sat, Dec 30, 2000 at 12:08:48PM -0800, John Baldwin wrote:
> >>
> >> On 30-Dec-00 Michael Harnois wrote:
> >> > panic: lockable mtx_enter() of lockmgr interlock when not legal @
> >> > ../../kern/kern_lock.c: 247
> >> >
> >> > which is
> >> >
> >> > mtx_enter(lkp->lk_interlock, MTX_DEF);
> >>
> >> We need to know where interrupts were disabled (since that is what makes the
> >> blockable mtx_enter() not legal). The most likely reason is that sched_lock
> >> is
> >> held. Take a crash dump if you can, and then examine the
> >> '__mtx_debug_sched_lock' variable. Esp. the mtxd_line and mtd_file members
> >> which tell us where sched_lock was last acquired.
> >
> > John,
> >
> > I can already supply the needed information.
> >
> > (kgdb) print __mtx_debug_sched_lock
> > $1 = {mtxd_witness = 0xc03d98f0, mtxd_held = {le_next = 0x0, le_prev =
> > 0x0},
> > mtxd_file = 0xc033c27c "../../kern/kern_sig.c", mtxd_line = 1111,
> > mtxd_description = 0xc0368cbf "sched lock"}
>
> That's line 1111 of sys/kern/kern_sig.c:
Yes, sorry I goofed up ... I am just very new to gdb...
> /*
> * Defer further processing for signals which are held,
> * except that stopped processes must be continued by SIGCONT.
> */
> mtx_enter(&sched_lock, MTX_SPIN);
> if (action == SIG_HOLD && (!(prop & SA_CONT) || p->p_stat != SSTOP)) {
> mtx_exit(&sched_lock, MTX_SPIN);
> return;
> }
>
>
> Hmm, ok, which signal is this?
In the case in point, it is SIGTSTP (Ctrl-Z)
--
Regards:
Szilveszter ADAM
Szeged University
Szeged Hungary
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
