[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070604202248.GA18668@dreamland.darkstar.lan>
Date: Mon, 4 Jun 2007 22:22:49 +0200
From: Luca Tettamanti <kronos.it@...il.com>
To: Avi Kivity <avi@...ranet.com>
Cc: kvm-devel@...ts.sf.net, linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [BUG] Oops with KVM-27
Hi,
Il Mon, Jun 04, 2007 at 12:35:37PM +0300, Avi Kivity ha scritto:
> Luca Tettamanti wrote:
> >Hello,
> >my kernel just exploded :)
> >
> >The host is running 2.6-git-current, with KVM modules from KVM-27
> >package. kernel is 32bit, SMP, with PREEMPT enabled, no HIGHMEM (but I'm
> >using CONFIG_VMSPLIT_3G_OPT=y). The CPU is a Core2 (hence I'm using
> >kvm-intel).
> >Guest was a Fedora7 setup DVD, which died somewhere during the
> >installation (anaconda was already active at that point). Bad news is
> >that I cannot reproduce the bug :|
> >
> Fortunately the trace clearly shows the problem (out of mmu working
> memory on guest context switch). The attached patch should fix it. Let
> me know if it works for you.
It turned out that it was somewhat reproducible with fedora installer.
With your patch it doesn't oops anymore.
While doing repeated tests with the installer I ran into another
(unrelated) problem. Sometimes the guest kernel hangs at boot at:
NET: Registered protocol family 2
with any kind of networking options (except for -net none, which works).
With -no-kvm it boots with any networking option.
The only difference in dmesg is that when KVM is enable the guest uses
the TSC:
NetLabel: unlabeled traffic allowed by default
-Time: tsc clocksource has been installed.
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
For reference this is the command line that I'm using:
./kvm-27/qemu/i386-softmmu/qemu -hda /home/kronos/tmp/fedora.img
-cdrom /home/kronos/tmp/boot.iso -boot d -net tap -net nic -m 256
and boot.iso is the fedora7 net install image (you can find it on any
mirror: fedora/linux/releases/7/Fedora/arch/os/images/boot.iso).
The guest kernel doesn't respond to sysrq, so I don't known exactly
where it's hanging. The stack trace on the host seems rather
uninteresting:
qemu S 00000002 2404 18905 7312 (NOTLB)
dca4db48 00000086 00000000 00000002 b0478900 eec4a0f0 b02f418b b0478900
0000000a 00000000 eec4a0f0 ef31ca70 267db8c3 000008c7 00003ea3 eec4a1fc
b1810980 efcc62a0 b0478900 b0129580 00000000 00000292 dca4db58 0023935c
Call Trace:
[<b02f418b>] _spin_unlock_irqrestore+0x34/0x58
[<b0129580>] __mod_timer+0x9d/0xa7
[<b02f2258>] schedule_timeout+0x70/0x8d
[<b02f418b>] _spin_unlock_irqrestore+0x34/0x58
[<b01291e0>] process_timeout+0x0/0x5
[<b02f2253>] schedule_timeout+0x6b/0x8d
[<b0171eb1>] do_select+0x399/0x3e7
[<b0172496>] __pollwait+0x0/0xac
[<b011c720>] default_wake_function+0x0/0xc
[<b0171766>] free_poll_entry+0xe/0x16
[<b0171786>] poll_freewait+0x18/0x4c
[<b0171abc>] do_sys_poll+0x302/0x327
[<b0172496>] __pollwait+0x0/0xac
[<b011c720>] default_wake_function+0x0/0xc
[<b011b26a>] task_rq_lock+0x36/0x5d
[<b02f3c59>] _spin_lock+0x33/0x3e
[<b02f4197>] _spin_unlock_irqrestore+0x40/0x58
[<b011c716>] try_to_wake_up+0x325/0x32f
[<b013b017>] mark_held_locks+0x39/0x53
[<b02f418b>] _spin_unlock_irqrestore+0x34/0x58
[<b0103ec0>] restore_nocheck+0x12/0x15
[<b013b1ee>] trace_hardirqs_on+0x11a/0x13d
[<b010679a>] do_IRQ+0xc4/0xde
[<b0103ec0>] restore_nocheck+0x12/0x15
[<b01721ed>] core_sys_select+0x2ee/0x30f
[<b0103189>] setup_sigcontext+0x105/0x189
[<b02f41cf>] _spin_unlock_irq+0x20/0x41
[<b013b1ee>] trace_hardirqs_on+0x11a/0x13d
[<b0103a56>] do_notify_resume+0x5d1/0x611
[<b02f41da>] _spin_unlock_irq+0x2b/0x41
[<b01039b4>] do_notify_resume+0x52f/0x611
[<b0103ec0>] restore_nocheck+0x12/0x15
[<b010898b>] convert_fxsr_from_user+0x26/0xe6
[<b01725e6>] sys_select+0xa4/0x187
[<b0103ec0>] restore_nocheck+0x12/0x15
[<b013b1ee>] trace_hardirqs_on+0x11a/0x13d
[<b0103e78>] syscall_call+0x7/0xb
=======================
qemu S CF9E5DC0 2996 18911 7312 (NOTLB)
cf9e5dd4 00000082 00000002 cf9e5dc0 cf9e5dbc 00000000 b013b1ee cf9e5ea0
00000007 00000001 d252b4f0 b194c030 70a8bf29 000008ac 0000a554 d252b5fc
b181a980 efcc62a0 00232330 00000003 00000000 00000000 cf9e5ea0 efcc62d4
Call Trace:
[<b013b1ee>] trace_hardirqs_on+0x11a/0x13d
[<b013de28>] futex_wait+0x251/0x3ed
[<b0134156>] hrtimer_wakeup+0x0/0x18
[<b013de19>] futex_wait+0x242/0x3ed
[<b011c720>] default_wake_function+0x0/0xc
[<b013e906>] do_futex+0x6c/0xaad
[<b012acf7>] sys_rt_sigqueueinfo+0x44/0x4e
[<b0135a4e>] getnstimeofday+0x30/0xbe
[<b0134627>] ktime_get_ts+0x16/0x44
[<b013f40f>] sys_futex+0xc8/0xda
[<b0103e78>] syscall_call+0x7/0xb
=======================
I'm attaching the dmesg for both -kvm and -no-kvm cases.
Luca
--
"La teoria e` quando sappiamo come funzionano le cose ma non funzionano.
La pratica e` quando le cose funzionano ma non sappiamo perche`.
Abbiamo unito la teoria e la pratica: le cose non funzionano piu` e non
sappiamo il perche`." -- A. Einstein
View attachment "serial-kvm.txt" of type "text/plain" (5329 bytes)
View attachment "serial-nokvm.txt" of type "text/plain" (8230 bytes)
Powered by blists - more mailing lists