Re: 2.6.16-rt10

[Simon Derr]

On Tue, 4 Apr 2006, Ingo Molnar wrote:

> 
> * Simon Derr <Simon.Derr@xxxxxxxx> wrote:
> 
> > On Tue, 28 Mar 2006, Ingo Molnar wrote:
> > 
> > First issue: 'BUG: udev:45 task might have lost a preemption check!'
> > 
> > When looking at the code in preempt_enable_no_resched(), why is the 
> > value of preempt_count() checked to be non-zero _after_ calling 
> > dec_preempt_count() ?
> > 
> > I saw several posts on this list claiming that this message is 
> > harmless, but I'd like to figure what's going on.
> 
> the warning means that doing a preempt_enable_no_resched() while being 
> in a preemptible section is most likely a bug, and that you could lose a 
> need_resched() check. (and introduce a scheduling latency) What's the 
> backtrace? This could be the sign of a not fully/correctly converted 
> arch/*/kernel/process.c (but i'm only guessing here).

Wow, thanks for the fast reply !

The backtrace is:

[<a00000010007fc50>] preempt_enable_no_resched+0xb0/0xe0
[<a000000100037510>] disabled_fph_fault+0x110/0x140
[<a0000001000378e0>] ia64_fault+0x240/0x11c0
[<a00000010000be40>] ia64_leave_kernel+0x0/0x290

But I must be severely misunderstanding something.

What I understood is that in preemptible sections preempt_count() is 
zero, and in non preemptible sections it is >0.

If preempt_count() is 1, then preempt_enable_no_resched() will decrement 
it and issue a warning. This is what happens in disabled_fph_fault().

Where am I wrong ?


> you should first check the PREEMPT_NONE kernel with PREEMPT_SOFTIRQS and 
> PREEMPT_HARDIRQS enabled. I.e. first check whether IRQ threading works.  
> Then enable all the other PREEMPT options one by one: PREEMPT_DESKTOP, 
> PREEMPT_RCU, PREEMPT_BKL. Only when all these work switch to PREEMPT_RT.
> 
Thanks, I'll try that.


	Simon.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/