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
