Bug#600992: further logs
On Fri, 2010-10-22 at 14:34 +0200, Tecnici wrote:
> > Do you get any output on the domU console corresponding with the
> > migration attempt? (perhaps increase log level with "echo 9 /proc/sysrq-trigger" before the suspend attempt)
>
> we just tried and the domU gave this output on its console:
>
> [ 151.400005] BUG: soft lockup - CPU#0 stuck for 61s! [xenwatch:12]
> [ 151.400005] Modules linked in: ext3 jbd mbcache dm_mod raid1 md_mod
> xen_netfront xen_blkfront
> [ 151.400005] CPU 0:
> [ 151.400005] Modules linked in: ext3 jbd mbcache dm_mod raid1 md_mod
> xen_netfront xen_blkfront
> [ 151.400005] Pid: 12, comm: xenwatch Not tainted 2.6.32-5-xen-amd64 #1
> [ 151.400005] RIP: e030:[<ffffffff810686d5>] [<ffffffff810686d5>]
> lock_hrtimer_base+0xa/0x3c
> [ 151.400005] RSP: e02b:ffff88003fe11d70 EFLAGS: 00000246
> [ 151.400005] RAX: ffff880002a40680 RBX: 0000000000000000 RCX:
> 0000000000000006
> [ 151.400005] RDX: ffff88003db31c50 RSI: ffff88003fe11da0 RDI:
> ffff880002a47820
> [ 151.400005] RBP: ffff880002a47820 R08: 0000000000000000 R09:
> 0000000000000000
> [ 151.400005] R10: ffff88003db2e050 R11: ffffffff8122b649 R12:
> ffff88003fe11da0
> [ 151.400005] R13: 0000000000000002 R14: ffff88003db31ca0 R15:
> ffff88003fe11df0
> [ 151.400005] FS: 00007f6840bc96e0(0000) GS:ffff880003557000(0000)
> knlGS:0000000000000000
> [ 151.400005] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 151.400005] CR2: 00007fc98d3e7000 CR3: 000000003eef3000 CR4:
> 0000000000000660
> [ 151.400005] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [ 151.400005] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [ 151.400005] Call Trace:
> [ 151.400005] [<ffffffff8106875b>] ? hrtimer_try_to_cancel+0x16/0x43
> [ 151.400005] [<ffffffff8122b649>] ? serial8250_suspend+0x0/0x48
> [ 151.400005] [<ffffffff81068794>] ? hrtimer_cancel+0xc/0x16
> [ 151.400005] [<ffffffffa0009147>] ? netfront_suspend+0x19/0x1d
> [xen_netfront]
> [ 151.400005] [<ffffffff811f569b>] ? xenbus_dev_suspend+0x1f/0x3b
> [ 151.400005] [<ffffffff81233872>] ? dpm_suspend_start+0x359/0x45b
> [ 151.400005] [<ffffffff811f2ca0>] ? shutdown_handler+0x15f/0x25c
> [ 151.400005] [<ffffffff8130b475>] ? mutex_lock+0xd/0x31
> [ 151.400005] [<ffffffff811f47ad>] ? xenwatch_thread+0x117/0x14a
> [ 151.400005] [<ffffffff81065afe>] ? autoremove_wake_function+0x0/0x2e
> [ 151.400005] [<ffffffff811f4696>] ? xenwatch_thread+0x0/0x14a
> [ 151.400005] [<ffffffff81065831>] ? kthread+0x79/0x81
> [ 151.400005] [<ffffffff81012baa>] ? child_rip+0xa/0x20
> [ 151.400005] [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b
> [ 151.400005] [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6
> [ 151.400005] [<ffffffff81012ba0>] ? child_rip+0x0/0x20
This stack trace is familiar, the netfront smartpoll feature is buggy
and so was disabled (this part is in the Debian kernel) but initial
attempts to allow it to be disabled were a bit buggy (the Debian kernel
is missing these fixes).
I'll pull in the additional patches:
fad2197bcb570350cb03c4ed789015baf0f86c81 xen/netfront: unconditionally initialize smartpoll hrtimer
00abe504c5cf268b73c45232aba56949af628349 xen/netfront: Fix another potential race condition
cb09635065163a933d0d00d077ddd9f0c0a908a1 Fix one race condition for netfront smartpoll logic
Ian.
--
Ian Campbell
Current Noise: Novembre - Zenith
abuse me. I'm so lame I sent a bug report to debian-devel-changes
-- Seen on #Debian
Reply to: