RE: FW: This kernel supports KDB but LKCD was invoked directly, not via KDB....

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



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click