Re: 2.6.12 PREEMPT_RT && PPC

[Ingo Molnar <mingo@elte.hu>]

* john cooper <john.cooper@timesys.com> wrote:

> Ingo,
>     Attached is a patch for 51-28 which brings PPC up to date for 
> 2.6.12 PREEMPT_RT.  My goal was to get a more recent vintage of this 
> work building and minimally booting for PPC.  Yet this has been stable 
> even under our internal stress tests.  We now have this running on 
> 8560 and 8260 PPC targets with a few others in the pipe.

great. I've applied most of your patch and have released the -51-37 
kernel. A couple of generic bits i did not apply.

> In the process of producing the patch I stumbled across a change 
> introduced in 51-15 where in the case of PREEMPT_RT it appears 
> hw_irq_controller.end() is never being called at the end of 
> do_hardirq(). This appears to be an oversight in the code and the 
> existing PPC openpic code does register a end() handler which it 
> expects to be called in order to terminate the interrupt.  Otherwise 
> interrupts at the current level are effectively disabled.

this change was fully intentional. Basically on PREEMPT_HARDIRQS, the 
'redirected' interrupt path is special already. Right now when an IRQ is 
redirected, we do the following: ->ack() in the hardirq handler and no 
->end() (so we keep the interrupt masked), then the handling of the IRQ 
sometime later in its interrupt thread, and an ->enable(). It's a bit 
unclean, but this results in minimal per-arch changes to the IRQ code.  
Nevertheless i have applied your change, but we need to get rid of this.

> There is also what I suspect to be some "leaking" of the 
> __RAW_LOCAL_ILLEGAL_MASK bit out of the local_irq*() API primitives as 
> the *flags argument. This may subsequently be used by non-local_irq*() 
> primitives and wind up unintentionally setting the 
> __RAW_LOCAL_ILLEGAL_MASK bit in the machine control register with 
> unpredictable results.

i have not applied the generic bits for this, because it should be 
solved within the raw_local_irq*() code: check for the illegal bit if 
IRQ debugging is turned on. We very much want to know about mismatched 
IRQ flags.

> Lastly there is a problem I've yet to isolate in 
> kernel/printk.c:release_console_sem() where the expansion of 
> spin_unlock_irq(&logbuf_lock) generating a call to 
> __raw_local_irq_enable() will lockup console output on PPC.  In the 
> interim this has been reverted to a spin_unlock() call for the case of 
> PREEMPT_RT && PPC.

i have not applied this one either, please investigate it further, it 
ought to work.

Also, i have not applied the timer.c change yet either: what kind of bug 
are you trying to fix there?

	Ingo