lock up in 6.2 (procs massively stuck in Giant)
John Baldwin
jhb at freebsd.org
Wed May 13 16:52:32 UTC 2009
On Wednesday 13 May 2009 11:41:22 am pluknet wrote:
> 2009/5/13 John Baldwin <jhb at freebsd.org>:
> > On Wednesday 13 May 2009 2:40:33 am pluknet wrote:
> >> 2009/5/13 pluknet <pluknet at gmail.com>:
> >> > 2009/5/13 John Baldwin <jhb at freebsd.org>:
> >> >> On Tuesday 12 May 2009 4:59:19 pm pluknet wrote:
> >> >>> Hi.
> >> >>>
> >> >>> From just another box (not from the first two mentioned earlier)
> >> >>> with a similar locking issue. If it would make sense, since there are
> >> >>> possibly a bit different conditions.
> >> >>> clock proc here is on swi4, I hope it's a non-important difference.
> >> >>>
> >> >>> 18 0 0 0 LL *Giant 0xd0a6b140 [swi4: clock
sio]
> >> >>> db> bt 18
> >> >>
> >> >> Ok, this is a known issue in 6.x. It is fixed in 6.4.
> >> >>
> >>
> >> Looking at the face of kern_timeout.c I suspect that was fixed in
r181012.
> >
> > No, this particular issue is fixed by a change to sched_4bsd.c in r179975.
> >
>
> Gah.. We constrained to use ule scheduler on 6.x (yes, I know that
> "it's known to be broken (c)"), since we have had a very bad interactivity
> on 4bsd on our workload. Ok, that's just another reason to move to 7.x.
Hmmm I would have thought ULE wouldn't have suffered from this bug. The
problem on 4BSD was if softclock ever blocked on Giant and the thread that
held Giant was on a run queue and pinned to a specific CPU but that another
userland thread was running on that CPU already, the userland thread would
never yield the CPU so long as it kept busy since the round robin timeout
would never run.
--
John Baldwin
More information about the freebsd-stable
mailing list