linux-mips
[Top] [All Lists]

Re: Problems with CONFIG_PREEMPT

To: Colin.Helliwell@Zarlink.Com
Subject: Re: Problems with CONFIG_PREEMPT
From: Jun Sun <jsun@mvista.com>
Date: Fri, 20 Dec 2002 15:53:57 -0800
Cc: linux-mips@linux-mips.org, rml@mvista.com, jsun@mvista.com
In-reply-to: <OF2066EDAB.79E8E12E-ON80256C95.00517ECB@zarlink.com>; from Colin.Helliwell@Zarlink.Com on Fri, Dec 20, 2002 at 02:51:24PM +0000
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <OF2066EDAB.79E8E12E-ON80256C95.00517ECB@zarlink.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.2.5i
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
> 
> 
> 
> 
> 

Attachment: pre-k-safe-with-new-fpu.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>