From: Avi Kivity <avi@redhat.com>
To: BRUNO CESAR RIBAS <ribas@c3sl.ufpr.br>
Cc: kvm@vger.kernel.org, Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: KVM Guest mmap.c bug
Date: Mon, 08 Mar 2010 15:32:19 +0200 [thread overview]
Message-ID: <4B94FC63.4060108@redhat.com> (raw)
In-Reply-To: <20100302202540.GA17774@c3sl.ufpr.br>
On 03/02/2010 10:25 PM, BRUNO CESAR RIBAS wrote:
> Hi,
>
> I run a bunch of virtual servers using KVM. And I a mmap.c bug on the guest
> machine. The virtual machines are "desktop servers" for Thin Clients.
>
> My host is running a 2.6.33 kernel and have 32GB of rami, opteron with
> amd-v.
>
> The guest is running 2.6.27.45 (tried 2.6.31.12, 2.6.32.9, 2.6.33), some
> guests are using 10GB, 4GB or 20GB of ram.
>
> My qemu-kvm version is 0.12.3
>
> All guests are using NFSROOT as the ROOT FS and virtio as the network
> driver.
>
> I run the guest with:
> kvm -cpu kvm64 -smp 4 -vnc :101 -daemonize -name ${NOME} -localtime -m $RAM
> -net nic,macaddr=$VLAN0,model=virtio,vlan=0 -net tap,vlan=0,ifname=${NOME}0\
> -net nic,macaddr=$VLAN121,model=virtio,vlan=121 -net tap,vlan=121,ifname=${NOME}121\
> -net nic,macaddr=$VLAN112,model=virtio,vlan=112 -net tap,vlan=112,ifname=${NOME}112\
> -kernel /root/vmlinuz-2.6.27.45-amd64-aufs-guest \
> -append "root=/dev/nfs rw ip=dhcp nfsroot=$5 init=/sbin/boot.sh"
>
>
> I have a machine running an identical kernel (without virtio stuff) for a
> dedicated machine (as it does not have amd-v) and it stays up for days and
> even months. But when running a guest machine with qemu-kvm i get some bug
> message and lots of process in D state and i can't 'ps aux' or look inside
> /proc and /sys without losing my shell (it hangs).
>
>
> In `console` I get the folowing message, repeated for different processor,
> different Pid and diferent mmap.c line (line 486 appears to).
>
> ------------[ cut here ]------------
> kernel BUG at mm/mmap.c:869!
> invalid opcode: 0000 [1] SMP
> CPU 2
> Pid: 31334, comm: nautilus Not tainted 2.6.27.45-amd64-aufs-guest-00267
> #2
> RIP: 0010:[<ffffffff8027b2e1>] [<ffffffff8027b2e1>] find_mergeable_ano
> f1/0x200
> RSP: 0000:ffff8804d933fb38 EFLAGS: 00010283
> RAX: ffff8804cb44b9a8 RBX: ffff8804cb44b978 RCX: ffff8804fe6d3088
> RDX: 00000000f4803000 RSI: ffff8804fe6d3088 RDI: ffff88049fa56138
> RBP: ffff88049fa56138 R08: ffff8804d933e000 R09: 0000000000000000
> R10: 00000000ffffffff R11: 00000000ffffffff R12: 0000000000100073
> R13: 0000000000100073 R14: 00000000f4803000 R15: ffffffff806ce6c0
> FS: 0000000000000000(0000) GS:ffff88051cc7d440(0063) knlGS:00000000f41
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 00000000f4803000 CR3: 00000004a7d39000 CR4: 00000000000006a0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process nautilus (pid: 31334, threadinfo ffff8804d933e000, task ffff880
> )
> Stack: ffffffff8052e62d 0000000000000000 0000000000000000 ffff88049fa5
> ffff88051a5aac40 ffffffff80280382 ffff8804cb41b790 ffff880498919018
> 0000000000000000 ffff88049f8dad20 00003ffffffff000 ffffffff802770aa
> Call Trace:
> [<ffffffff8052e62d>] ? _spin_lock_irq+0xd/0x10
> [<ffffffff80280382>] ? anon_vma_prepare+0x52/0x100
> [<ffffffff802770aa>] ? handle_mm_fault+0x65a/0x900
> [<ffffffff802de6d8>] ? proc_alloc_inode+0x58/0x90
> [<ffffffff8052e545>] ? __down_read+0x85/0xbc
> [<ffffffff80223331>] ? do_page_fault+0x2a1/0xab0
> [<ffffffff803d6899>] ? vsnprintf+0x4d9/0x750
> [<ffffffff8029d7a1>] ? do_lookup+0x81/0x240
> [<ffffffff8027265d>] ? zone_statistics+0x7d/0x80
> [<ffffffff8052ea3a>] ? error_exit+0x0/0x70
> [<ffffffff803d706d>] ? copy_user_generic_string+0x2d/0x40
> [<ffffffff802e35ec>] ? proc_file_read+0x12c/0x2e0
> [<ffffffff802e34c0>] ? proc_file_read+0x0/0x2e0
> [<ffffffff802dec1a>] ? proc_reg_read+0x8a/0xe0
> [<ffffffff80295995>] ? vfs_read+0xb5/0x160
> [<ffffffff80295b2e>] ? sys_read+0x4e/0x90
> [<ffffffff80227004>] ? ia32_sysret+0x0/0x5
>
>
> Code: 29 d0 48 c1 e8 0c 48 01 f8 48 3b 83 88 00 00 00 0f 85 5b fe ff ff
> 78 e9 c5 fe ff ff 0f 1f 00 31 f6 31 db e9 a9 fe ff ff<0f> 0b eb fe 66
> 1f 84 00 00 00 00 00 48 83 ec 08 48 8b
> RIP [<ffffffff8027b2e1>] find_mergeable_anon_vma+0x1f1/0x200
> RSP<ffff8804d933fb38>
> ---[ end trace e5ca25224cd7d1d4 ]---
>
>
> Does anyone has a sugestion? Where to look? What else should I trace?
>
>
It looks unrelated to kvm, though of course random memory corruption
cannot be ruled out.
Is npt enabled on the host (cat /sys/module/kvm_amd/parameters/npt)?
Andrea, any idea?
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-03-08 13:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 20:25 KVM Guest mmap.c bug BRUNO CESAR RIBAS
2010-03-08 13:32 ` Avi Kivity [this message]
2010-03-08 14:49 ` Andrea Arcangeli
2010-03-09 18:46 ` Bruno Cesar Ribas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B94FC63.4060108@redhat.com \
--to=avi@redhat.com \
--cc=aarcange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=ribas@c3sl.ufpr.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox