Hello all.
The issue I have discovered while fitting Alchemy KGDB driver into 2.6.24
is that the following MIPS KGDB code from arch/mips/kernel/kgdb.c:
void handle_exception(struct pt_regs *regs)
{
[...]
/* In SMP mode, __flush_cache_all does IPI */
local_irq_enable();
__flush_cache_all();
}
enables interrupts too early in the bootup, well before start_kernel() enables
them (althought that only happens for a very short period of time -- before
the assembly code starts to restore the CPU context to return from exception),
and by misfortune the timer interrupt fires immediately -- which the MIPS
timer handler is not ready to take that early, before time_init(). Prior
to 2.6.24, the Alchemy code had its own timer handler which was prepared to be
called that early, so everything used to "go smoothly". Frankly speaking, I
don't yet know what happens on other platforms, maybe only the Alchemy is
susceptible to this issue -- due to unmasking the timer interrupt in
arch_init_irq() which as I'm seeing now no other MIPS platform seems to be
doing... this seems to be the cause of the lockup then, and I'll try to deal
with this in the Linux/MIPS tree...
Actually, I have myself pushed the change that introduced that
local_irq_enable() there -- we had to do this because MIPS smp_call_function()
called as a result of __flush_cache_all() woudl complain if called with IRQs
disabled. This place seemed safe enough to enable interrupt because all KGDB
"work" had been already done at this point. Now it's finally blown up. :-)
As this issue seems to couple closely with the cache flushes, I will use a
chance to clarify a few matters in this area. First of all, why the flushes
are necessary at all? I have also noticed the CACHE_FLUSH_IS_SAFE macro used
to indicate that it's safe to flush the caches on the given arch (it's set to
0 on MIPS) -- the documentation suggests that this poses danger only on SMP
(probably due to the MIPS smp_call_function(), right?), why CONFIG_SMP is not
checked then?
WBR, Sergei
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Kgdb-bugreport mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
