LOR sleepq/scrlock
John Baldwin
jhb at freebsd.org
Fri Apr 18 19:05:10 UTC 2008
On Thursday 10 April 2008 06:33:40 pm Aristedes Maniatis wrote:
>
> >> http://www.ish.com.au/s/LOR/1.jpg
> >> http://www.ish.com.au/s/LOR/2.jpg
> >> http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2])
> >
> > These are all garbage in kuickshow. :(
>
> They work fine for me in Firefox. But don't know what sort of jpegs
> the Sony camera saves. Anyhow I've also now resaved them as png (about
> twice the size). Please let me know if that worked.
>
> http://www.ish.com.au/s/LOR/1.png , etc
kuickshow had issues still, but FF worked ok. The specific LOR at the end is
real, but a minor one. Basically, the console driver locks
(e.g. "sio", "scrlock") are higher in the order than the various thread
locks, so any printf while holding a thread lock will trigger a LOR. The
real problem at the bottom of the screen though is a real issue. It's a LOR
of two different sleepqueue chain locks. The problem is that when
setrunnable() encounters a swapped out thread it tries to wakeup proc0, but
if proc0 is asleep (which is typical) then its thread lock is a sleep queue
chain lock, so waking up a swapped out thread from wakeup() will usually
trigger this LOR.
I think the best fix is to not have setrunnable() kick proc0 directly.
Perhaps setrunnable() should return an int and return true if proc0 needs to
be awakened and false otherwise. Then the the sleepq code (b/c only sleeping
threads can be swapped out anyway) can return that value from
sleepq_resume_thread() and can call kick_proc0() directly once it has dropped
all of its own locks.
--
John Baldwin
More information about the freebsd-stable
mailing list