On Thu, Nov 09, 2006 at 03:04:18PM +1100, Keith Owens wrote: Hi Keith, > All the kernel debug style tools (kdb, kgdb, nlkd, netdump, lkcd, > crash, kdump etc.) have a common requirement, they need to do a crash > stop of the systems. This means stopping all the cpus, even if some of > the cpus are spinning disabled. In addition, each cpu has to save > enough state to start the diagnosis of the problem. > > * Each debug style tool has written its own code for interrupting the > other cpus and for saving cpu state. > > * Some tools try a normal IPI first then send a non-maskable interrupt > after a delay. > > * Some tools always send a NMI first, which can result in incomplete or > wrong machine state if NMI arrives at the wrong time. >
What kind of problem one can run into if NMI is sent directly instead of trying an normal IPI first? On a general note, I am not sure how well suited this infrastructure is for crash dump needs. We are trying to follow one theme and that is run a bare minimal code after a system crash to increase reliabitity. Avoid taking locks avoid relying on crashed task's stack etc. (if possible). Of course it is an ideal situation and we have not achieved that state but roughly that seems to be the long term goal. Looking at the patches it looks like it introduces lots of code to be run after crash and also uses smp_processor_id() which introduces a dependency on stack. This poses problem in stack overflow cases. Fernando from valinux, introduced safe_smp_processor_id() call to read apic id from LAPIC instead of relying on the thread's stack. As of today, the crash path is no safe from stack overflow but we hope that someday it would be. So I think crash dump will be a little special case and we need to be careful while introducing extra code that new code will be able to run even if system is in very bad state. (for example stack overflow). Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
