On Thu, 2005-03-31 at 13:03 +0200, Ingo Molnar wrote: > * Steven Rostedt <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
