Re: kgdb support in vanilla 2.6.2

["Amit S. Kale" <amitkale@emsyssoft.com>]

On Thursday 04 Mar 2004 6:20 am, Andi Kleen wrote:
> On Wed, 03 Mar 2004 16:43:47 -0800
>
> George Anzinger <george@mvista.com> wrote:
> > Andi Kleen wrote:
> > > On Tue, Mar 02, 2004 at 01:27:51PM -0800, Andrew Morton wrote:
> > >>George Anzinger <george@mvista.com> wrote:
> > >>> Often it is not clear just why we are in the stub, given that
> > >>>we trap such things as kernel page faults, NMI watchdog, BUG macros
> > >>> and such.
> > >>
> > >>Yes, that can be confusing.  A little printk on the console prior to
> > >>entering the debugger would be nice.
> > >
> > > What I did for kdb and panic some time ago was to flash the keyboard
> > > lights. If you use a unique frequency (different from kdb
> > > and from panic) it works quite nicely.

Flashing keyboard lights is far simpler compared to a printk. Printk is too 
heavy. Once a system is unstable, it's more important to run into kgdb code 
asap. Calling printk and co may be too much.

> >
> > Assuming a key board and a clear (no spin locks) path to it.  Still it
> > only says
>
> I think it's reasonable to just write to the keyboard without any locking.
> The keyboard driver will recover.

Flashing keyboard lights is easy on x86 and x86_64 platforms. Is that easy on 
ppc workstations/servers? Embedded boards don't have keyboards.

>
> > we are in kgdb, now why.
>
> The big advantage is that it works even when you are in X (like most
> people) printks are often not visible.

Yep.
-- 
Amit Kale
EmSysSoft (http://www.emsyssoft.com)
KGDB: Linux Kernel Source Level Debugger (http://kgdb.sourceforge.net)