Re: Issues with current KGDB on i386

On Mon, 2005-12-26 at 12:44 +0530, Amit Kale wrote:
> On Saturday 24 Dec 2005 1:10 am, George Anzinger wrote:
> > Amit Kale wrote:
> > > Looking at present i386 code and starting from basics (html format for a
> > > change).
> > >
> > > do_nmi->
> > >   nmi_callback() if non-zero
> > >           If CONFIG_SYSCTL this is set to unknown_nmi_panic_callback() ->
> > >                   if (!(reason & 0xc))
> > >                           die_nmi();
> > >     else default_do_nmi() ->
> > >           if(!(reason & 0xc))
> > >                   if (notify_die(DIE_NMI_IPI) == NOTIFY_STOP)
> > >                           return
> > >                   nmi_watchdog_tick()->
> > >                           after 5 seconds die_nmi()
> > >           if (notify_die(DIE_NMI) == NOTIFY_STOP)
> > >                           return
> > >
> > > die_nmi ->
> > >   if (notify_die(DIE_NMIWATCHDOG) == NOTIFY_STOP)
> > >           return;
> > >   .... panic etc.
> > >
> > > We should be doing this in kgdb_notify
> > > ...
> > > else if ((cmd == DIE_NMI || cmd == DIE_NMI_IPI ||
> > >   cmd == DIE_NMIWATCHDOG) && atomic_read(&debugger_active))
> > >   kgdb_nmi_hook();
> > >   return NOTIFY_STOP;
> > > else if (cmd == DIE_NMI_IPI || cmd == DIE_NMI || user_mode(regs) ||
> > >           (cmd == DIE_DEBUG && atomic_read(&debugger_active))
> > >   return NOTIFY_DONE;
> > >
> > > kgdb_handle_exception();
> >

I am planning to check the fix on monday.
here is interdiff of the i386-lite.patch for your review:
---------------------------------------------------------------
diff -u linux-2.6.15-SMP/arch/i386/kernel/kgdb.c linux-2.6.15-
SMP/arch/i386/kernel/kgdb.c
--- linux-2.6.15-SMP/arch/i386/kernel/kgdb.c 2006-01-11
10:58:25.000000000 +0530
+++ linux-2.6.15-SMP/arch/i386/kernel/kgdb.c 2006-01-11
10:58:25.000000000 +0530
@@ -268,15 +268,16 @@
        } else if (cmd == DIE_PAGE_FAULT)
                /* A normal page fault, ignore. */
                return NOTIFY_DONE;
- else if (cmd == DIE_NMI && atomic_read(&debugger_active)) {
+ else if ((cmd == DIE_NMI || cmd == DIE_NMI_IPI ||
+ cmd == DIE_NMIWATCHDOG) && atomic_read(&debugger_active)) {
                /* CPU roundup */
- kgdb_nmihook(smp_processor_id(), regs);
- return NOTIFY_STOP;
- } else if (cmd == DIE_NMI_IPI || user_mode(regs) ||
- (cmd == DIE_DEBUG && atomic_read(&debugger_active)))
- /* Normal watchdog event or userspace debugging, or spurious
- * debug exception, ignore. */
- return NOTIFY_DONE;
+ kgdb_nmihook(smp_processor_id(), regs);
+ return NOTIFY_STOP;
+ } else if (cmd == DIE_NMI_IPI || cmd == DIE_NMI || user_mode(regs) ||
+ (cmd == DIE_DEBUG && atomic_read(&debugger_active)))
+ /* Normal watchdog event or userspace debugging, or spurious
+ * debug exception, ignore. */
+ return NOTIFY_DONE;

        kgdb_handle_exception(args->trapnr, args->signr, args->err,
regs);

@@ -313 +313,0 @@
-};
---------------------------------------------------------------

thanks
-Jitendra
LinSysSoft Technologies
Ask me about KGDB Pro
http://www.linsyssoft.com/Kgdbpro.html

> > It looks like this (correctly) sends DIE_NMIWATCHDOG &&
> > !debugger_active to kgdb_handle_exception().  It is important in this
> > case to also return NOTIFY_STOP so that the caller to die_nmi() gets
> > control again.  We have carefully crafted the nmi_watchdog to restart
> > the watchdog counts in this case, thus allowing the system to continue
> > as if the nmi_watchdog had not detected a problem (possibly the user
> > even fixed it while in kgdb code :)).
> 
> Very true. Reproducing most of the NMI problems is difficult. Let's make this 
> change if on-one finds any problems either during testing or code inspection.
> 
> > Hmm... In looking at this:
> >   "(cmd == DIE_DEBUG && atomic_read(&debugger_active))
> >     return NOTIFY_DONE;
> >
> > Don't we have a race here.  In particular if debugger_active is set
> > prior to cpu roundup, here we will ignore a breakpoint from another
> > cpu.  Seems to me that DIE_DEBUG && !user_mode should _always_ go to
> > kgdb_handle_exception().  There are, of course, other possibliities,
> > but we do NOT want to loose the breakpoint notify.
> 
> Breakpoints are notified via DIE_INT3 when kprobes is enabled and DIE_TRAP 
> otherwise. We hold other cpus from excecuting while single stepping, so if a 
> DIE_DEBUG occurs a cpu while another CPU is alread in debug, it has to be a 
> spurious exception.
> 
> -Amit
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Kgdb-bugreport mailing list
> Kgdb-bugreport@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
> 
> 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642