I attached the additional patch I was referring to.
Unfortunately it is against our internel kernel base. I have not had
time to adapt it to the linux-mips.org base yet. But it should be
easy to adapt it.
Let me know if it makes things better.
Jun
On Fri, Dec 20, 2002 at 02:51:24PM +0000, Colin.Helliwell@Zarlink.Com wrote:
>
> 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
>
>
>
>
>
pre-k-safe-with-new-fpu.patch
Description: Text document
|