Bug#592463: xen-linux-system-2.6.26-2-xen-amd64: domU kernel freeze on xfs location
Hi Ian,
Thanks for your response. The kernel is linux-image-2.6.26-2-xen-amd64,
installed via the xen-linux-system-2.6.26-2-xen-amd4 package. The issue
occurred inside of a PV domU.
Best Regards,
Mark
On Wed, Aug 11, 2010 at 04:13:11PM +0100, Ian Campbell wrote:
> Thanks for your report.
>
> Looking at the stack trace I don't see much which is Xen-specific. The
> only XFS vs. Xen interaction which I am aware of is the one addressed by
> http://xenbits.xen.org/linux-2.6.18-xen.hg?rev/9bf1ddd0f6bf but I don't
> think that is implicated here.
>
> Could this perhaps be a XFS rather than Xen bug? For example google
> finds http://www.mail-archive.com/samba@lists.samba.org/msg101509.html
> which looks (superficially) similar. While googling I also got the
> (perhaps mistaken) impression that lockdep warnings from XFS were not
> uncommon in the past.
>
> I'm not really that familiar with XFS so I don't know to suggest next,
> anyone else on debian-kernel have any ideas? I had a look over the
> fs/xfs history in git and nothing leaps out at me.
>
> BTW, which exact kernel version do you have installed?
>
> Ian.
>
> On Tue, 2010-08-10 at 10:25 +0100, sysadmin@campbell-lange.net wrote:
> > Package: xen-linux-system-2.6.26-2-xen-amd64
> > Severity: important
> >
> >
> > Hello,
> >
> > Yesterday we had a domU PV host freeze up in a file location. The
> > following log was received:
> >
> > [20108008.237603] BUG: soft lockup - CPU#0 stuck for 61s! [smbd:16411]
> > [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys
> > [20108008.237603] CPU 0:
> > [20108008.237603] Modules linked in: appletalk ppdev parport_pc lp parport ipv6 xfs evdev ext3 jbd mbcache thermal_sys
> > [20108008.237603] Pid: 16411, comm: smbd Not tainted 2.6.26-2-xen-amd64 #1
> > [20108008.237603] RIP: e030:[<ffffffffa0072d36>] [<ffffffffa0072d36>] :xfs:xfs_iext_get_ext 0xa/0x5a
> > [20108008.237603] RSP: e02b:ffff8800534dfa30 EFLAGS: 00000202
> > [20108008.237603] RAX: 000000000000008d RBX: ffff8800534dfbe8 RCX: 000000000000008d
> > [20108008.237603] RDX: ffff8800534dfc30 RSI: 000000000000008c RDI: ffff88006436bb60
> > [20108008.237603] RBP: ffff88008d43c8d0 R08: 000000000000008d R09: 0000000000000100
> > [20108008.237603] R10: ffff8800fdba73c0 R11: 0000000000000000 R12: ffff8800534dfbc8
> > [20108008.237603] R13: ffff88006436bb60 R14: ffff8800534dfc30 R15: ffff8800534dfc2c
> > [20108008.237603] FS: 00007f4198b83700(0000) GS:ffffffff8053a000(0000) knlGS:0000000000000000
> > [20108008.237603] CS: e033 DS: 0000 ES: 0000
> > [20108008.237603] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [20108008.237603] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [20108008.237603]
> > [20108008.237603] Call Trace:
> > [20108008.237603] [<ffffffffa00550d7>] ? :xfs:xfs_bmap_search_multi_extents 0x78/0xda
> > [20108008.237603] [<ffffffffa0055194>] ? :xfs:xfs_bmap_search_extents 0x5b/0xe6
> > [20108008.237603] [<ffffffffa005b1df>] ? :xfs:xfs_bmapi 0x26e/0xf76
> > [20108008.237603] [<ffffffff80436b47>] ? error_exit 0x0/0x69
> > [20108008.237603] [<ffffffff80436b47>] ? error_exit 0x0/0x69
> > [20108008.237603] [<ffffffffa0096441>] ? :xfs:xfs_zero_eof 0xc0/0x16a
> > [20108008.237603] [<ffffffffa0096b0e>] ? :xfs:xfs_write 0x344/0x722
> > [20108008.237603] [<ffffffff8028a1ef>] ? do_sync_write 0xc9/0x10c
> > [20108008.237603] [<ffffffff8020e7bc>] ? get_nsec_offset 0x9/0x2c
> > [20108008.237603] [<ffffffff802992dc>] ? __posix_lock_file 0x3c1/0x3f6
> > [20108008.237603] [<ffffffff8023f6c1>] ? autoremove_wake_function 0x0/0x2e
> > [20108008.237603] [<ffffffff8028a999>] ? vfs_write 0xad/0x156
> > [20108008.237603] [<ffffffff8028b024>] ? sys_pwrite64 0x50/0x70
> > [20108008.237603] [<ffffffff802964a2>] ? sys_fcntl 0x2eb/0x2f7
> > [20108008.237603] [<ffffffff8020b528>] ? system_call 0x68/0x6d
> > [20108008.237603] [<ffffffff8020b4c0>] ? system_call 0x0/0x6d
> > [20108008.237603]
> >
> > This domU could not be rebooted, and had to be xm destroy then
> > recreated again before the filesystem was accessible again. This
> > machine has been running successfully for over 6 months before this
> > issue occurred, and we run a number of other 2.6.26-2-xen machines
> > that have not had this issue (fingers crossed!). If there is any
> > explanation of this, how to avoid, or if it has been fixed in a newer
> > kernel, this would be ideal.
> >
> > Thanks
> >
> >
> > -- System Information:
> > Debian Release: 5.0.5
> > APT prefers stable
> > APT policy: (500, 'stable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/bash
> >
> >
> >
>
> --
> Ian Campbell
>
> Bennett's Laws of Horticulture:
> (1) Houses are for people to live in.
> (2) Gardens are for plants to live in.
> (3) There is no such thing as a houseplant.
>
Reply to: