linux-mips
[Top] [All Lists]

Re: Problems with CONFIG_PREEMPT

To: Jun Sun <jsun@mvista.com>
Subject: Re: Problems with CONFIG_PREEMPT
From: Colin.Helliwell@Zarlink.Com
Date: Fri, 20 Dec 2002 14:51:24 +0000
Cc: linux-mips@linux-mips.org, rml@mvista.com
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
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






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