![]() | |||||||||||
Messages in this thread |
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2005-03-22 14:01 [from the cache] ©2003-2008 | |||||||||||