FW: [lkcd-general] This kernel supports KDB but LKCD was invoked directly, not via KDB....

[Bruce Edge]

If I call dump before kdb, the dump saves something to disk as reboots.
If I use the following instead, ie: call kdb before dump it spins waiting for disk IO to complete.

> You have a misapplied patch to arch/i386/kernel/traps.c.  It 
> is calling
> lkcd before kdb.  die() in arch/i386/kernel/traps.c should 
> look like this.
> 
> void die(const char * str, struct pt_regs * regs, long err)
> {
> 	console_verbose();
> 	spin_lock_irq(&die_lock);
> 	bust_spinlocks(1);
> 	handle_BUG(regs);
> 	printk("%s: %04lx\n", str, err & 0xffff);
> 	show_registers(regs);
> 	bust_spinlocks(0);
> 	spin_unlock_irq(&die_lock);
> #ifdef  CONFIG_KDB
> 	kdb_diemsg = str;
> 	kdb(KDB_REASON_OOPS, err, regs);
> #endif  /* CONFIG_KDB */
> 	dump((char *)str, regs);
> 	do_exit(SIGSEGV);
> }
> 
> Note that dump() is called after kdb.
> 

It appears that kdb is doing something to the processor state that is preventing brw_kiovec() writes from completing.
I added a bunch of printk's to figure out where it was hanging, and it just ends up spinning in kiobuf_wait_for_io() (fs/iobuf.c).
The kiobuf->io-count never decrements.

It doesn't do this if I set a breakpoint at dump_execute_memdump(). The dump completes successfully when I type "go" after it hits the breakpoint.

Is this a case of kdb stopping all but one CPU, thereby not letting the thread handling the disc writes run?
Or, is some interrupt mask being set by kdb that the breakpoint re-enables?

Thnaks, Bruce


Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.