Sergei Shtylyov wrote:
> 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?
The cache flush is needed such that you will hit your breakpoints
(software breakpoints that is), or when you re-install the original
instructions. Right now there is no "dirty bit" that is set to
indicate the need for the actual cache flush.
> 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?
>
>
I assume you are asking specifically about the irq_enable(). In
theory, if it is SMP and and not safe for cache flush, that would be the
time that the irq's should be enabled.
Design wise you are correct in that it is not good to enable the
interrupts until all the proper setup is completed. This just means
that for the mips arch an extra arch specific flag is needed for when to
use a local processor cache flush, vs an all processor cache flush
(which would be toggled in start_kernel()). The all processor cache
flush would only be applicable in the first place at the point that all
the processors are online and the system is ready to transition to
running in interrupt driven mode.
The instruction cache definitely needs to be flushed before returning
from the exception context if you are changing back to back instructions.
Jason.
-------------------------------------------------------------------------
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
