From: Paolo Bonzini <pbonzini@redhat.com>
To: "Gonglei (Arei)" <arei.gonglei@huawei.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Huangpeng (Peter)" <peter.huangpeng@huawei.com>,
"wangxin (U)" <wangxinxin.wang@huawei.com>,
"Huangweidong (C)" <weidong.huang@huawei.com>,
"benoit@irqsave.net" <benoit@irqsave.net>,
"Herongguang (Stephen)" <herongguang.he@huawei.com>
Subject: Re: [Qemu-devel] [BUG] Redhat-6.4_64bit-guest kernel panic with cpu-passthrough and guest numa
Date: Thu, 27 Nov 2014 18:20:10 +0100 [thread overview]
Message-ID: <54775D4A.8080709@redhat.com> (raw)
In-Reply-To: <33183CC9F5247A488A2544077AF1902086E041A5@SZXEMA503-MBS.china.huawei.com>
On 27/11/2014 14:00, Gonglei (Arei) wrote:
>>
>> Running a redhat-6.4-64bit (kernel 2.6.32-358.el6.x86_64) or elder guest on
>> qemu-2.1, with kvm enabled and -cpu host, non default cpu-topology and guest
>> numa
>> I'm seeing a reliable kernel panic from the guest shortly after boot. It is
>> happening in
>> find_busiest_group().
>>
>> We also found it happend since commit
>> 787aaf5703a702094f395db6795e74230282cd62 by git bisect.
>>
>> The reproducer:
>>
>> (1) full qemu cmd line:
>> qemu-system-x86_64 -machine pc-i440fx-2.1,accel=kvm,usb=off \
>> -cpu host -m 16384 \
>> -smp 16,sockets=2,cores=4,threads=2 \
>> -object memory-backend-ram,size=8192M,id=ram-node0 \
>> -numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \
>> -object memory-backend-ram,size=8192M,id=ram-node1 \
>> -numa node,nodeid=1,cpus=8-15,memdev=ram-node1 \
>> -boot c -drive file=/data/wxin/vm/redhat_6.4_64 \
>> -vnc 0.0.0.0:0 -device
>> cirrus-vga,id=video0,vgamem_mb=8,bus=pci.0,addr=0x1.0x4 \
>> -msg timestamp=on
>>
>> (2)the guest kernel messages:
Can you find what line of kernel/sched.c it is?
Thanks,
Paolo
>> divide error: 0000 [#1] SMP
>> last sysfs file:
>> CPU 0
>> Modules linked in:
>>
>> Pid: 1, comm: swapper Not tainted 2.6.32-358.el6.x86_64 #1 QEMU Standard
>> PC (i440FX + PIIX, 1996)
>> RIP: 0010:[<ffffffff81059a9c>] [<ffffffff81059a9c>]
>> find_busiest_group+0x55c/0x9f0
>> RSP: 0018:ffff88023c85f9e0 EFLAGS: 00010046
>> RAX: 0000000000100000 RBX: ffff88023c85fbdc RCX: 0000000000000000
>> RDX: 0000000000000000 RSI: 0000000000000010 RDI: 0000000000000010
>> RBP: ffff88023c85fb50 R08: ffff88023ca16c10 R09: 0000000000000000
>> R10: 0000000000000001 R11: 0000000000000000 R12: 00000000ffffff01
>> R13: 0000000000016700 R14: ffffffffffffffff R15: 0000000000000000
>> FS: 0000000000000000(0000) GS:ffff880028200000(0000)
>> knlGS:0000000000000000
>> CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
>> CR2: 0000000000000000 CR3: 0000000001a85000 CR4: 00000000000407f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process swapper (pid: 1, threadinfo ffff88023c85e000, task ffff88043d27c040)
>> Stack:
>> ffff88023c85faf0 ffff88023c85fa60 ffff88023c85fbc8 0000000200000000
>> <d> 0000000100000000 ffff880028210b60 0000000100000001
>> 0000000000000008
>> <d> 0000000000016700 0000000000016700 ffff88023ca16c00
>> 0000000000016700
>> Call Trace:
>> [<ffffffff8150da2a>] thread_return+0x398/0x76e
>> [<ffffffff8150e555>] schedule_timeout+0x215/0x2e0
>> [<ffffffff81065905>] ? enqueue_entity+0x125/0x410
>> [<ffffffff8150e1d3>] wait_for_common+0x123/0x180
>> [<ffffffff81063310>] ? default_wake_function+0x0/0x20
>> [<ffffffff8150e2ed>] wait_for_completion+0x1d/0x20
>> [<ffffffff81096a89>] kthread_create+0x99/0x120
>> [<ffffffff81090950>] ? worker_thread+0x0/0x2a0
>> [<ffffffff81167769>] ? alternate_node_alloc+0xc9/0xe0
>> [<ffffffff810908d9>] create_workqueue_thread+0x59/0xd0
>> [<ffffffff8150ebce>] ? mutex_lock+0x1e/0x50
>> [<ffffffff810911bd>] __create_workqueue_key+0x14d/0x200
>> [<ffffffff81c47233>] init_workqueues+0x9f/0xb1
>> [<ffffffff81c2788c>] kernel_init+0x25e/0x2fe
>> [<ffffffff8100c0ca>] child_rip+0xa/0x20
>> [<ffffffff81c2762e>] ? kernel_init+0x0/0x2fe
>> [<ffffffff8100c0c0>] ? child_rip+0x0/0x20
>> Code: 8b b5 b0 fe ff ff 48 8b bd b8 fe ff ff e8 9d 85 ff ff 0f 1f 44 00 00 48 8b 95 e0
>> fe ff ff 48 8b 45 a8 8b 4a 08 48 c1 e0 0a 31 d2 <48> f7 f1 48 8b 4d b0 48 89 45 a0
>> 31 c0 48 85 c9 74 0c 48 8b 45
>> RIP [<ffffffff81059a9c>] find_busiest_group+0x55c/0x9f0
>> RSP <ffff88023c85f9e0>
>> divide error: 0000 [#2]
>> ---[ end trace d7d20afc6dd05e71 ]---
next prev parent reply other threads:[~2014-11-27 17:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 13:00 [Qemu-devel] [BUG] Redhat-6.4_64bit-guest kernel panic with cpu-passthrough and guest numa Gonglei (Arei)
2014-11-27 17:20 ` Paolo Bonzini [this message]
2014-11-28 2:38 ` Gonglei
2014-12-01 9:48 ` Paolo Bonzini
2014-12-02 3:41 ` Gonglei
2014-12-02 3:43 ` Gonglei
-- strict thread matches above, loose matches on Subject: below --
2014-11-27 12:58 Gonglei (Arei)
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=54775D4A.8080709@redhat.com \
--to=pbonzini@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=benoit@irqsave.net \
--cc=herongguang.he@huawei.com \
--cc=peter.huangpeng@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=wangxinxin.wang@huawei.com \
--cc=weidong.huang@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).