Think I'm ok with respect to interrupt handling, but what does making
globals "safe or taken care of" consist of?
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
cc: linux-mips@linux-mips.org, rml@mvista.com, jsun@mvista.com
19-Dec-2002 05:59 Subject: Re: Problems with CONFIG_PREEMPT
PM
On Thu, Dec 19, 2002 at 09:10:40AM +0000, Colin.Helliwell@Zarlink.Com
wrote:
>
> Thanks for the patch, but unfortunately the problem is still the same.
If the problem happens very soon after you boot up, there is something
*obviously* wrong. The most common problem is that you have an interupt
handling path not going through standard do_IRQ(). Then you need to
do similar treatment like those in ll_timer_interrupt().
The second thing is to look for any *new* global variables you may
introduce in your kernel. Most of current global variables are either
safe or taken care of (Although another update patch will come out
today or tomorrow to really close the final hole we have).
> I'm
> not sure whether it occurs as a result of interrupts, or just after a
> certain amount of scheduler 'activity' as it sits there copying the
initrd
> into ram disk. A few interrupts are enabled, but its only the MIPS timer
> which should be generating any interrupts at that point (I'll check that,
> in case its relevant).
FYI, I have mips kernel with initrd running just fine with preemptible
kernel.
In fact, it has passed some very stressful tests with initrd.
> I presume the change from "sti()" to "__sti()" was a semantic (or SMP)
> thing, since the former is #defined to the latter anyway? Please note
also
> the following modification which was required to 2.4.19:
>
This is true. Since our kernel had synchronize_irq() added long time ago,
I probably forgot about it when I created the pre-k patch.
Jun
