Re: Problems with CONFIG_PREEMPT

[Jun Sun <jsun@mvista.com>]

Several possibilities:

1) Not all MIPS boards can run pre-k.  At minimum, you need to use
NEW_TIME_C, Or else you have to take a lot of stuff youself. 

2) Not sure if all MIPS patches are in RML's patch.  If you pass the URL
pointer, I can take a look.

3) Even with all above taken care of, there are still unsolved issues
(such as math emul not pre-k safe, some cache operations, etc).
However, these problems usually are much harder to show up.  You won't
see them unless you delibrately want to. :-)

Jun

On Mon, Dec 16, 2002 at 01:58:11PM +0000, Colin.Helliwell@Zarlink.Com wrote:
> I've been porting the MIPS kernel to our system-on-chip hardware
> (4KEc-based) and have encountered a problem with a pre-emptible patch. The
> original kernel was the 2.4.19 from the CVS server, onto which I applied
> Robert Love's preemptible patch (preempt-kernel-rml-2.4.19-2.patch), plus
> the addition of a #include to softirq.h, and a missing definition for
> release_irqlock() in hardirq.h.
> I've found that when CONFIG_PREEMPT is set, it no longer loads the
> (non-compressed) initrd correctly - about 1.8MB through loading (2MB total)
> I get a Data Bus Error. A typical call trace shown by the oops is shown
> below, and looks a little 'confused' to me, so I'm thinking there may be
> some stack corruption going on?
> 
> Address         Function
> 
> 801174fc        tasklet_hi_action
> 801af0a4        printChipInfo
> 801af0a4        printChipInfo
> 8013bf50        sys_write
> 801089c4        stack_done
> 80108b28        reschedule
> 801133d0        _call_console_drivers
> 80113ad8        release_console_sem
> 80113848        printk
> 801506b8        sys_ioctl
> 801af0f8        printChipInfo
> 8014ccd4        sys_mkdir
> 801af0a4        printChipInfo
> 80100470        init
> 80100470        init
> 80100840        prepare_namespace
> 80100470        init
> 8010049c        init
> 8010352c        kernel_thread
> 80100420        _stext
> 8010351c        kernel_thread
> 
> 
> I wondered if anyone had any thoughts about what might be causing this, or
> had seen this occuring before - were there perhaps some changes made just
> after this point in time (now in the 2.5.x kernel)?
> 
> 
> 
> Thanks.
> 
> 
> 
>