Re: 2.6.16-rt10

[Ingo Molnar <mingo@elte.hu>]

* Simon Derr <Simon.Derr@bull.net> wrote:

> On Tue, 28 Mar 2006, Ingo Molnar wrote:
> 
> > 
> > * Simon Derr <simon.derr@bull.net> wrote:
> > 
> > > On Mon, 27 Mar 2006, Ingo Molnar wrote:
> > > 
> > > > i've released -rt10
> > > 
> > > Is anyone working on a port of this patch to the IA64 architecture ?
> > 
> > not that i know of. If someone wants to do that, take a look at the 
> > x86_64 changes (or ppc/mips/i386 changes) to get an idea. These are the 
> > rough steps needed:
> > [snip]
> 
> 
> Work in progress... (based on -rt11)
> So far I have a kernel that almost boots, but not quite.
> 
> 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).

> My boot process is stuck later when insmod loads the driver for the 
> MPT Fusion SCSI adapter. It's waiting for a second interrupt to 
> arrive, and that never happens.
> 
> I see that the -rt patch touches many drivers by changing calls to 
> local_irq_save (and friends), changing the type of the semaphores, but 
> the MPT driver makes no use of these.
> 
> Any ideas ?

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.

	Ingo