Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote:
> * Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> your patch looks good, i've added it to my tree and have uploaded the 
> -26-00 patch. It boots fine on my testbox, except for some new messages:
> 
>  knodemgrd_0/902: BUG in __down_complete at kernel/rt.c:1568
>   [<c0103956>] dump_stack+0x23/0x25 (20)
>   [<c0130dcd>] down_trylock+0x1fb/0x200 (48)
>   [<c0364ee2>] nodemgr_host_thread+0xd0/0x17b (48)
>   [<c0100d4d>] kernel_thread_helper+0x5/0xb (136249364)
>  ---------------------------
>  | preempt count: 00000001 ]
>  | 1-level deep critical section nesting:
>  ----------------------------------------
>  .. [<c0133a75>] .... print_traces+0x1b/0x52
>  .....[<c0103956>] ..   ( <= dump_stack+0x23/0x25)
> 
> this goes away if i revert your patch. It seems the reason is that 
> trylock hasnt been updated to use the pending-owner logic?

Damn, now that I have a comparable kernel to look at, I see where that
1568 is. I did see these, but they went away when I changed the logic to
handle the BKL, and I thought it was related. 

Since this happened with the trylock, do you see anyway that a pending
owner can cause problems?  Maybe this has to do with is_locked. Now a
pending owner makes this ambiguous. Since the lock has a owner, and a
task can't get it if it is of lower priority than the pending owner, but
it can get it if it is higher. Now is it locked?  My implementation was
to be safe and say that it is locked.

I'll play around some more with this.

-- Steve