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/[email protected]/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, [email protected] 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. > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
