On Mar 23, 2008, at 10:32, Andrew Doran wrote:
It avoids the problem.
Right. That's what I figured.
I think it's case of trying to understand where the dealock is
coming from.
It looks like a lock order reversal. I think what is happening is
that one
thread is acquiring:
kernel_lock -> kq_lock
.. and another is acquiring:
kq_lock -> kernel_lock.
They both deadlock waiting for each other's lock. Given a quick look I
haven't been able to find that.
Makes sense. I can't build a kernel right now due to the rumpfs problem that's affecting things in -current, but after that, I could take a swing at this.
I'll chat with you off-list about the idea of maybe putting "I'm being locked by XXX" in both of those two places, then can look at the output. My Ultra2 is on a serial console, so printf-style debugging is often my choice for such things. :-)
- Chris