Date: Tue, 22 May 2001 15:22:26 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: smp@FreeBSD.ORG Subject: RE: more recursive mutex panics- help me out with the One True w Message-ID: <Pine.LNX.4.21.0105221520070.10376-100000@zeppo.feral.com> In-Reply-To: <XFMail.010522133730.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > lrecursed on non-recursive lock (sleep mutex) process lock @
> > ../../kern/kern_lock.c:262
> > first acquired @ ../../kern/kern_sig.c:447
> > panic: recurse
> > panic
> > Stopped at
>
> That doesn't seem to be from any problems in your code. I'm somewhat
> curious why lockmgr is being called during a signal operation however,
> as that seems to be the problem you've run into. I'd need a backtrace
> to be more certain however.
>
> > So- 2 questions:
> >
> >
> > 1. Are the defines for grabbing/releasing Giant acceptable in kthread
> > context?
>
> They look fine.
Great! THanks!
>
> > 2. Is the msleep on lbolt a bad idea?
>
> The msleep is fine, the &lbolt part I'm not an expert on, so I'm not sure
> if it is evil or not. :)
Actually, I think it might have been the msleep that might have caused all of
this. Instead of sleeping on lbolt, I do:
msleep(isp_kthread, &isp->isp_lock,
PRIBIO, "isp_fcthrd", hz);
which is a lot cleaner and closer to what I wanted anyway (nobody will wake me
up- but I just wanted to sleep with the lock off for a second). I've been
running my tests since this morning and I haven't died yet- it used to do
within a few hours. Well, we'll see.
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0105221520070.10376-100000>