* Re: Problems with CONFIG_PREEMPT
@ 2002-12-17 8:27 Colin.Helliwell
2002-12-17 18:03 ` Jun Sun
0 siblings, 1 reply; 8+ messages in thread
From: Colin.Helliwell @ 2002-12-17 8:27 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
NEW_TIME_C is set. URL to the patch is:
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
We ultimately want to add in real-time support, such as Ingo's O(1)
scheduler - if this is 'complete' for MIPS. I don't know if it would be
better just to go for this in one hit, or if we'd need the preemption
sorted out anyway first. Or should we just go to a 2.5.x kernel instead?
Colin
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
cc: linux-mips@linux-mips.org, jsun@mvista.com
16-Dec-2002 08:45 Subject: Re: Problems with CONFIG_PREEMPT
PM
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Problems with CONFIG_PREEMPT
2002-12-17 8:27 Problems with CONFIG_PREEMPT Colin.Helliwell
@ 2002-12-17 18:03 ` Jun Sun
0 siblings, 0 replies; 8+ messages in thread
From: Jun Sun @ 2002-12-17 18:03 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, jsun, rml
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Tue, Dec 17, 2002 at 08:27:16AM +0000, Colin.Helliwell@Zarlink.Com wrote:
>
> NEW_TIME_C is set. URL to the patch is:
> http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
>
There are some bits missing. Not sure if it is related to your problem or not.
Robert, please take the MIPS preemptible kernel update patch.
> We ultimately want to add in real-time support, such as Ingo's O(1)
> scheduler - if this is 'complete' for MIPS.
O(1) shortens process dispatching time, usually not a big time saver
unless you have *lots* of process and/or you are doing frequent context
switches.
Another patch which is probably more important is the Ingo's breaking
selected big lock patch. That will preemption work more effectively.
> I don't know if it would be
> better just to go for this in one hit, or if we'd need the preemption
> sorted out anyway first.
You do have to sort them out one by one. (Or you get them all by becoming
mvista customer. :-0)
> Or should we just go to a 2.5.x kernel instead?
We'd love to have more people bang on 2.5 MIPS *grin* ...
Jun
[-- Attachment #2: 021217-mips-2.4-prek-update.patch --]
[-- Type: text/plain, Size: 2511 bytes --]
Additional patch for MIPS against RML's 2.4.19-2 preemptiable kernel patch.
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
Jun
diff -Nru link/arch/mips/kernel/irq.c.orig link/arch/mips/kernel/irq.c
--- link/arch/mips/kernel/irq.c.orig Tue Dec 17 09:44:29 2002
+++ link/arch/mips/kernel/irq.c Tue Dec 17 09:44:45 2002
@@ -507,13 +507,13 @@
}
current->preempt_count ++;
- sti();
+ __sti();
if (user_mode(regs)) {
schedule();
} else {
preempt_schedule();
}
- cli();
+ __cli();
}
#endif
diff -Nru link/arch/mips/kernel/time.c.orig link/arch/mips/kernel/time.c
--- link/arch/mips/kernel/time.c.orig Mon Dec 2 16:56:03 2002
+++ link/arch/mips/kernel/time.c Tue Dec 17 09:53:37 2002
@@ -416,6 +416,8 @@
{
int cpu = smp_processor_id();
+ preempt_disable();
+
irq_enter(cpu, irq);
kstat.irqs[cpu][irq]++;
@@ -426,12 +428,34 @@
if (softirq_pending(cpu))
do_softirq();
+
+#if defined(CONFIG_PREEMPT)
+ while (--current->preempt_count == 0) {
+ db_assert(intr_off());
+ db_assert(!in_interrupt());
+
+ if (current->need_resched == 0) {
+ break;
+ }
+
+ current->preempt_count ++;
+ __sti();
+ if (user_mode(regs)) {
+ schedule();
+ } else {
+ preempt_schedule();
+ }
+ __cli();
+ }
+#endif
}
asmlinkage void ll_local_timer_interrupt(int irq, struct pt_regs *regs)
{
int cpu = smp_processor_id();
+ preempt_disable();
+
irq_enter(cpu, irq);
kstat.irqs[cpu][irq]++;
@@ -442,6 +466,26 @@
if (softirq_pending(cpu))
do_softirq();
+
+#if defined(CONFIG_PREEMPT)
+ while (--current->preempt_count == 0) {
+ db_assert(intr_off());
+ db_assert(!in_interrupt());
+
+ if (current->need_resched == 0) {
+ break;
+ }
+
+ current->preempt_count ++;
+ __sti();
+ if (user_mode(regs)) {
+ schedule();
+ } else {
+ preempt_schedule();
+ }
+ __cli();
+ }
+#endif
}
/*
diff -Nru link/include/asm-mips/softirq.h.orig link/include/asm-mips/softirq.h
--- link/include/asm-mips/softirq.h.orig Tue Dec 17 09:44:29 2002
+++ link/include/asm-mips/softirq.h Tue Dec 17 09:54:13 2002
@@ -10,6 +10,9 @@
#ifndef _ASM_SOFTIRQ_H
#define _ASM_SOFTIRQ_H
+#include <linux/sched.h>
+#include <linux/spinlock.h>
+
#include <asm/atomic.h>
#include <asm/hardirq.h>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problems with CONFIG_PREEMPT
@ 2002-12-20 14:51 Colin.Helliwell
2002-12-20 23:53 ` Jun Sun
0 siblings, 1 reply; 8+ messages in thread
From: Colin.Helliwell @ 2002-12-20 14:51 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips, rml
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
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Problems with CONFIG_PREEMPT
2002-12-20 14:51 Colin.Helliwell
@ 2002-12-20 23:53 ` Jun Sun
0 siblings, 0 replies; 8+ messages in thread
From: Jun Sun @ 2002-12-20 23:53 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, rml, jsun
[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]
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 #2: pre-k-safe-with-new-fpu.patch --]
[-- Type: text/plain, Size: 4964 bytes --]
diff -Nru linux2/arch/mips/kernel/traps.c.orig linux2/arch/mips/kernel/traps.c
--- linux2/arch/mips/kernel/traps.c.orig Wed Dec 18 17:41:11 2002
+++ linux2/arch/mips/kernel/traps.c Fri Dec 20 15:05:08 2002
@@ -131,12 +131,14 @@
else if (get_user(value, vaddr))
signal = SIGSEGV;
else {
+ preempt_disable();
if (ll_task == NULL || ll_task == current) {
ll_bit = 1;
} else {
ll_bit = 0;
}
ll_task = current;
+ preempt_enable();
regp->regs[(opcode & RT) >> 16] = value;
}
if (compute_return_epc(regp))
@@ -168,6 +170,7 @@
sc_ops++;
#endif
+ preempt_disable();
if ((unsigned long)vaddr & 3)
signal = SIGBUS;
else if (ll_bit == 0 || ll_task != current)
@@ -176,6 +179,7 @@
signal = SIGSEGV;
else
regp->regs[reg] = 1;
+ preempt_enable();
if (compute_return_epc(regp))
return;
if (signal)
@@ -551,6 +555,9 @@
TRACE_TRAP_ENTRY(CAUSE_EXCCODE(regs), CAUSE_EPC(regs));
if (fcr31 & FPU_CSR_UNI_X) {
int sig;
+
+ preempt_disable();
+
/*
* Unimplemented operation exception. If we've got the
* full software emulator on-board, let's use it...
@@ -576,6 +583,8 @@
/* Restore the hardware register state */
restore_fp(current);
+ preempt_enable();
+
/* If something went wrong, signal */
if (sig)
force_sig(sig, current);
@@ -756,6 +765,8 @@
die_if_kernel("do_cpu invoked from kernel context!", regs);
+ preempt_disable();
+
own_fpu();
if (current->used_math) { /* Using the FPU again. */
restore_fp(current);
@@ -772,6 +783,8 @@
}
}
+ preempt_enable();
+
TRACE_TRAP_EXIT();
return;
diff -Nru linux2/arch/mips/kernel/process.c.orig linux2/arch/mips/kernel/process.c
--- linux2/arch/mips/kernel/process.c.orig Wed Dec 18 17:41:11 2002
+++ linux2/arch/mips/kernel/process.c Fri Dec 20 15:04:38 2002
@@ -80,9 +80,11 @@
childksp = (unsigned long)p + KERNEL_STACK_SIZE - 32;
+ preempt_disable();
if (is_fpu_owner()) {
save_fp(p);
}
+ preempt_enable();
/* set up new TSS. */
childregs = (struct pt_regs *) childksp - 1;
diff -Nru linux2/arch/mips/kernel/signal.c.orig linux2/arch/mips/kernel/signal.c
--- linux2/arch/mips/kernel/signal.c.orig Wed Dec 18 17:41:11 2002
+++ linux2/arch/mips/kernel/signal.c Fri Dec 20 15:04:54 2002
@@ -214,6 +214,8 @@
err |= __get_user(current->used_math, &sc->sc_used_math);
+ preempt_disable();
+
if (current->used_math) {
own_fpu();
err |= restore_fp_context(sc);
@@ -221,6 +223,8 @@
loose_fpu();
}
+ preempt_enable();
+
return err;
}
@@ -348,6 +352,8 @@
if (!current->used_math)
goto out;
+ preempt_disable();
+
/* There exists FP thread state that may be trashed by signal */
if (!is_fpu_owner()) {
own_fpu();
@@ -357,6 +363,8 @@
/* fp is active. Save context from FPU */
err |= save_fp_context(sc);
+ preempt_enable();
+
out:
return err;
}
diff -Nru linux2/include/asm-mips/pgalloc.h.orig linux2/include/asm-mips/pgalloc.h
--- linux2/include/asm-mips/pgalloc.h.orig Mon Dec 16 18:16:04 2002
+++ linux2/include/asm-mips/pgalloc.h Wed Dec 18 17:46:06 2002
@@ -11,6 +11,7 @@
#include <linux/config.h>
#include <linux/mm.h>
+#include <linux/sched.h>
#include <asm/fixmap.h>
/* TLB flushing:
@@ -84,20 +85,26 @@
{
unsigned long *ret;
+ preempt_disable();
if((ret = pgd_quicklist) != NULL) {
pgd_quicklist = (unsigned long *)(*ret);
ret[0] = ret[1];
pgtable_cache_size--;
- } else
+ preempt_enable();
+ } else {
+ preempt_enable();
ret = (unsigned long *)get_pgd_slow();
+ }
return (pgd_t *)ret;
}
extern __inline__ void free_pgd_fast(pgd_t *pgd)
{
+ preempt_disable();
*(unsigned long *)pgd = (unsigned long) pgd_quicklist;
pgd_quicklist = (unsigned long *) pgd;
pgtable_cache_size++;
+ preempt_enable();
}
extern __inline__ void free_pgd_slow(pgd_t *pgd)
@@ -109,19 +116,23 @@
{
unsigned long *ret;
+ preempt_disable();
if((ret = (unsigned long *)pte_quicklist) != NULL) {
pte_quicklist = (unsigned long *)(*ret);
ret[0] = ret[1];
pgtable_cache_size--;
}
+ preempt_enable();
return (pte_t *)ret;
}
extern __inline__ void free_pte_fast(pte_t *pte)
{
+ preempt_disable();
*(unsigned long *)pte = (unsigned long) pte_quicklist;
pte_quicklist = (unsigned long *) pte;
pgtable_cache_size++;
+ preempt_enable();
}
extern __inline__ void free_pte_slow(pte_t *pte)
diff -Nru linux2/include/asm-mips/fpu.h.orig linux2/include/asm-mips/fpu.h
--- linux2/include/asm-mips/fpu.h.orig Wed Dec 18 17:53:17 2002
+++ linux2/include/asm-mips/fpu.h Fri Dec 20 15:03:32 2002
@@ -120,11 +120,14 @@
static inline unsigned long long *get_fpu_regs(struct task_struct *tsk)
{
+ preempt_disable();
if(mips_cpu.options & MIPS_CPU_FPU) {
if ((tsk == current) && is_fpu_owner())
_save_fp(current);
+ preempt_enable();
return (unsigned long long *)&tsk->thread.fpu.hard.fp_regs[0];
} else {
+ preempt_enable();
return (unsigned long long *)tsk->thread.fpu.soft.regs;
}
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problems with CONFIG_PREEMPT
@ 2002-12-19 9:10 Colin.Helliwell
2002-12-19 17:59 ` Jun Sun
0 siblings, 1 reply; 8+ messages in thread
From: Colin.Helliwell @ 2002-12-19 9:10 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips, rml
Thanks for the patch, but unfortunately the problem is still the same. 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).
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:
diff -u -p -r1.1 -r1.2
--- scratch/include/asm-mips/hardirq.h 2002/09/26 15:58:11 1.1
+++ scratch/include/asm-mips/hardirq.h 2002/12/12 13:15:03 1.2
@@ -42,7 +42,7 @@
#define irq_exit(cpu, irq) (local_irq_count(cpu)--)
#define synchronize_irq() barrier();
-
+#define release_irqlock(cpu) do { } while (0)
#else
#include <asm/atomic.h>
(We had a look at the 2.5 (head) kernel, but this seems to have some wrong
coding, and doesn't build straight off. Things like duplicate #defines
ALIGN and a conditional branch instruction with only one operand!)
Jun Sun
<jsun@mvista.com> To: Colin.Helliwell@Zarlink.Com
Sent by: cc: linux-mips@linux-mips.org, jsun@mvista.com, rml@mvista.com
linux-mips-bounce@lin Subject: Re: Problems with CONFIG_PREEMPT
ux-mips.org
17-Dec-2002 06:03 PM
On Tue, Dec 17, 2002 at 08:27:16AM +0000, Colin.Helliwell@Zarlink.Com
wrote:
>
> NEW_TIME_C is set. URL to the patch is:
>
http://www.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.19-2.patch
>
There are some bits missing. Not sure if it is related to your problem or
not.
Robert, please take the MIPS preemptible kernel update patch.
> We ultimately want to add in real-time support, such as Ingo's O(1)
> scheduler - if this is 'complete' for MIPS.
O(1) shortens process dispatching time, usually not a big time saver
unless you have *lots* of process and/or you are doing frequent context
switches.
Another patch which is probably more important is the Ingo's breaking
selected big lock patch. That will preemption work more effectively.
> I don't know if it would be
> better just to go for this in one hit, or if we'd need the preemption
> sorted out anyway first.
You do have to sort them out one by one. (Or you get them all by becoming
mvista customer. :-0)
> Or should we just go to a 2.5.x kernel instead?
We'd love to have more people bang on 2.5 MIPS *grin* ...
Jun
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Problems with CONFIG_PREEMPT
2002-12-19 9:10 Colin.Helliwell
@ 2002-12-19 17:59 ` Jun Sun
0 siblings, 0 replies; 8+ messages in thread
From: Jun Sun @ 2002-12-19 17:59 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, rml, jsun
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Problems with CONFIG_PREEMPT
@ 2002-12-16 13:58 Colin.Helliwell
2002-12-16 20:45 ` Jun Sun
0 siblings, 1 reply; 8+ messages in thread
From: Colin.Helliwell @ 2002-12-16 13:58 UTC (permalink / raw)
To: linux-mips
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problems with CONFIG_PREEMPT
2002-12-16 13:58 Colin.Helliwell
@ 2002-12-16 20:45 ` Jun Sun
0 siblings, 0 replies; 8+ messages in thread
From: Jun Sun @ 2002-12-16 20:45 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, jsun
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.
>
>
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-12-20 23:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-17 8:27 Problems with CONFIG_PREEMPT Colin.Helliwell
2002-12-17 18:03 ` Jun Sun
-- strict thread matches above, loose matches on Subject: below --
2002-12-20 14:51 Colin.Helliwell
2002-12-20 23:53 ` Jun Sun
2002-12-19 9:10 Colin.Helliwell
2002-12-19 17:59 ` Jun Sun
2002-12-16 13:58 Colin.Helliwell
2002-12-16 20:45 ` Jun Sun
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.