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.
|