[Top] [All Lists]

Re: xfsdump stuck in io_schedule

To: Zlatko Calusic <zlatko.calusic@xxxxxxxx>
Subject: Re: xfsdump stuck in io_schedule
From: Chris Wedgwood <cw@xxxxxxxx>
Date: Sat, 16 Nov 2002 12:59:42 -0800
Cc: Andrew Morton <akpm@xxxxxxxxx>, Andi Kleen <ak@xxxxxxx>, linux-xfs@xxxxxxxxxxx, Keith Owens <kaos@xxxxxxxxxx>
In-reply-to: <87zns9xwtk.fsf@xxxxxxxxxxxxxx>
References: <dnfzu3yw8u.fsf@xxxxxxxxxxxxxxxxx> <20021115135233.A13882@xxxxxxxxxxxxxxxx> <dnlm3v9ebk.fsf@xxxxxxxxxxxxxxxxx> <20021115140635.A31836@xxxxxxxxxxxxx> <dnr8dmj1i1.fsf@xxxxxxxxxxxxxxxxx> <3DD57602.857AD62D@xxxxxxxxx> <87zns9xwtk.fsf@xxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4i
On Sat, Nov 16, 2002 at 06:12:55PM +0100, Zlatko Calusic wrote:

> Chris, unfortunately here I have exactly the same problems with the
> code from CVS pulled today, so the bug is not really solved.

I'll try and older kernel then and see if I can reproduce it, for
whatever reason right now, I'm having no luck making this happen

Oddly, I *always* got the hang at the start of a dump which followed a
previous dump... and at the start xfsdump does call blkstat at about
where the problem was occurring so I'm getting suspicious of that

I have code that uses blkstat as a test, I'll see if I can cause a
lockup running that in a loop whilst grinding the VM hard.

> pressed Alt-Sysrq-T after the xfsdump got stuck and got this:

> [xfs_bulkstat+2123/2824] xfs_bulkstat+0x84b/0xb08
> [xfs_inactive_free_eofblocks+176/548] xfs_inactive_free_eofblocks+0xb0/0x224

I cant see how those can both be in the same call path.  Have you
tried without preempt?  I wondered if that might aggregate things?

> I have kdb compiled in the kernel but I forgot how to use (drop
> into) it. Pressing Pause key, like documentation says, doesn't work.

2.5.x is missing the hook for this, Keith sent me this patch so enable
<PAUSE> again.

--- drivers/char/keyboard.c.orig        Sat Oct 12 18:29:31 2002
+++ drivers/char/keyboard.c     Wed Nov 13 08:58:22 2002
@@ -41,6 +41,9 @@
 #include <linux/vt_kern.h>
 #include <linux/sysrq.h>
 #include <linux/input.h>
+#ifdef CONFIG_KDB
+#include <linux/kdb.h>
+#endif /* CONFIG_KDB */
 static void kbd_disconnect(struct input_handle *handle);
 extern void ctrl_alt_del(void);
@@ -1029,6 +1032,13 @@
                if (emulate_raw(vc, keycode, !down << 7))
                        printk(KERN_WARNING "keyboard.c: can't emulate rawmode 
for keycode %d\n", keycode);
+#ifdef CONFIG_KDB
+       if (down && keycode == KEY_PAUSE && kdb_on) {
+               kdb(KDB_REASON_KEYBOARD, 0, kbd_pt_regs);
+               return;
+       }
+#endif /* CONFIG_KDB */
 #ifdef CONFIG_MAGIC_SYSRQ             /* Handle the SysRq Hack */
        if (keycode == KEY_SYSRQ && !rep) {
                sysrq_down = sysrq_alt && down;

'GO' doesn't continue running as expected though, kdb just renters as
if it hadn't noticed <PAUSE> had been released.  For me this wasn't a
problem however.


<Prev in Thread] Current Thread [Next in Thread>