From: hangaohuai <hangaohuai@huawei.com>
To: Chris Friesen <chris.friesen@windriver.com>
Cc: <herongguang.he@huawei.com>,
"wangxin (U)" <wangxinxin.wang@huawei.com>,
<fangying1@huawei.com>, <qemu-devel@nongnu.org>,
<kvm@vger.kernel.org>, <rkrcmar@redhat.com>,
<pbonzini@redhat.com>
Subject: Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration
Date: Mon, 13 Feb 2017 21:19:46 +0800 [thread overview]
Message-ID: <58A1B272.1000402@huawei.com> (raw)
In-Reply-To: <589DDC05.9010807@windriver.com>
Hi, Chris Friesen.
We notice that you can reliably trigger the BUG during the live-migration stress test, however we can't.
Could you descripe your test steps so that we can re-trigger the BUG and get more information about it ?
On 2017/2/10 23:28, Chris Friesen wrote:
>
> Well, not so much solved as worked around it.
>
> It seems that the problem only showed up on Broadwell, which made us wonder about something hardware specific.
>
> Setting "kvm-intel.eptad=0" in the kernel boot args seems to mask the problem for us.
>
> Chris
>
> On 02/10/2017 03:11 AM, Herongguang (Stephen) wrote:
>> Hi, Chris Friesen, did you solve the problem?
>>
>> On 2017/2/9 22:37, Herongguang (Stephen) wrote:
>>> Hi.
>>> I had a problem when I just repeatedly live migrate a vm between two compute
>>> nodes.
>>> The phenomenon was that the KVM module was crashed and then the host rebooted.
>>> However I cannot reliably trigger this BUG.
>>>
>>> The backtrace is the same as http://www.spinics.net/lists/kvm/msg138475.html.
>>>
>>> The crash is triggered when function __rmap_clear_dirty is invoked and an
>>> invalid page(0x000000007f183000) is visited.
>>> The value %rdi is 0x000000007f183000, which is obviously not a valid kernel
>>> pointer for x86_64.
>>> The assembly of __rmap_clear_dirty is:
>>> 0xffffffffa04d9ac0 <__rmap_clear_dirty>: callq 0xffffffff816543d0
>>> <ftrace_caller>
>>> 0xffffffffa04d9ac5 <__rmap_clear_dirty+5>: push %rbp
>>> 0xffffffffa04d9ac6 <__rmap_clear_dirty+6>: mov %rsp,%rbp
>>> 0xffffffffa04d9ac9 <__rmap_clear_dirty+9>: push %rbx
>>> 0xffffffffa04d9aca <__rmap_clear_dirty+10>: sub $0x18,%rsp
>>> 0xffffffffa04d9ace <__rmap_clear_dirty+14>: mov (%rsi),%rdi
>>> 0xffffffffa04d9ad1 <__rmap_clear_dirty+17>: mov %gs:0x28,%rax
>>> 0xffffffffa04d9ada <__rmap_clear_dirty+26>: mov %rax,-0x10(%rbp)
>>> 0xffffffffa04d9ade <__rmap_clear_dirty+30>: xor %eax,%eax
>>> 0xffffffffa04d9ae0 <__rmap_clear_dirty+32>: test %rdi,%rdi
>>> 0xffffffffa04d9ae3 <__rmap_clear_dirty+35>: je 0xffffffffa04d9b78
>>> 0xffffffffa04d9ae9 <__rmap_clear_dirty+41>: test $0x1,%dil
>>> 0xffffffffa04d9aed <__rmap_clear_dirty+45>: je 0xffffffffa04d9b98
>>> 0xffffffffa04d9af3 <__rmap_clear_dirty+51>: and $0xfffffffffffffffe,%rdi
>>> 0xffffffffa04d9af7 <__rmap_clear_dirty+55>: movl $0x0,-0x18(%rbp)
>>> 0xffffffffa04d9afe <__rmap_clear_dirty+62>: mov %rdi,-0x20(%rbp)
>>> 0xffffffffa04d9b02 <__rmap_clear_dirty+66>: mov (%rdi),%rdi
>>> 0xffffffffa04d9b05 <__rmap_clear_dirty+69>: test %rdi,%rdi
>>> ...
>>>
>>> The details of the environment is:
>>> Host info: x86_64 CentOS 7 kernel (3.10.0-327.36.58.10_2.x86_64, slightly
>>> modified). The CPU is Broadwell Intel(R) Xeon(R) CPU E5-2618L v4 @ 2.20GHz.
>>> Kmod info: version is 4.4.36
>>> What I know is that the parameter PML(Page Modification Logging) is enabled by
>>> default.
>>> # cat /sys/module/kvm_intel/parameters/pml
>>> # Y
>>>
>>> Below is the crash message:
>>> [1548777.924180] kvm: zapping shadow pages for mmio generation wraparound
>>> [1548777.947844] HTB: quantum of class 10001 is big. Consider r2q change.
>>> [1548778.185389] kvm: zapping shadow pages for mmio generation wraparound
>>> [1548778.994801] BUG: unable to handle kernel paging request at 000000007f183000
>>> [1548779.002135] IP: [<ffffffffa04d9b0a>] __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.009151] PGD 1f8452067 PUD 0
>>> [1548779.012774] Thread overran stack, or stack corrupted
>>> [1548779.018076] Oops: 0000 [#1] SMP
>>> [1548779.027050] collected_len = 1048570, LOG_BUF_LEN_LOCAL = 1048576
>>> [1548779.042039] kbox: no notify die func register. no need to notify
>>> [1548779.048392] do nothing after die!
>>> [1548779.052071] Modules linked in: kboxdriver(O) kbox(O) sch_htb
>>> ip_set_hash_net ip6table_filter ip6_tables iptable_filter igb_uio(OE) uio
>>> bridge dm_service_time dm_multipath iscsi_tcp libiscsi_tcp libiscsi
>>> scsi_transport_iscsi 8021q garp stp mrp llc vfat fat isofs ext4 jbd2 xfs
>>> sha512_generic dev_connlimit(O) bum(O) ip_set nfnetlink prio(O) nat(O)
>>> vport_vxlan(O) openvswitch(O) nf_defrag_ipv6 gre ib_uverbs(OVE) hotpatch(OE)
>>> sigma_serial(O) pmcint(O) guest_kbox_ram(O) signo_catch(O) mlx4_ib(OVE)
>>> mlx4_en(OVE) vxlan ip6_udp_tunnel udp_tunnel ib_sa(OVE) ib_mad(OVE) ptp
>>> ib_core(OVE) ib_addr(OVE) pps_core ib_netlink(OVE) intel_powerclamp coretemp
>>> intel_rapl crc32_pclmul crc32c_intel ipmi_devintf(OVE) ghash_clmulni_intel
>>> mlx4_core(OVE) aesni_intel kvm_intel(O) igb(OVE) lrw gf128mul i2c_algo_bit
>>> glue_helper
>>> [1548779.125577] iTCO_wdt ablk_helper kvm(O) iTCO_vendor_support sg cryptd
>>> compat(OVE) dca sb_edac i2c_i801 kbox_pci(OVE) i2c_core edac_core pcspkr
>>> lpc_ich shpchp mfd_core ipmi_si(OVE) ipmi_msghandler(OVE) nf_conntrack_ipv4
>>> nf_defrag_ipv4 vhost_net(O) tun(O) vhost(O) macvtap macvlan vfio_pci irqbypass
>>> vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp nf_nat_proto_sctp nf_nat
>>> nf_conntrack sctp libcrc32c ip_tables ext3 mbcache jbd sd_mod crc_t10dif
>>> crct10dif_generic ahci crct10dif_pclmul crct10dif_common libahci mpt2sas(OVE)
>>> libata raid_class scsi_transport_sas dm_mod [last unloaded: kbox]
>>> [1548779.178704] CPU: 35 PID: 33769 Comm: migration Tainted: G OE
>>> ----V------- 3.10.0-327.36.58.10_2.x86_64 #1
>>> [1548779.189855] Hardware name: HUAWEI TECHNOLOGIES CO.,LTD.
>>> CH80GPUB8/CH80GPUB8, BIOS GPUBV201 06/18/2015
>>> [1548779.199585] task: ffff880123da0000 ti: ffff8801a8068000 task.ti:
>>> ffff8801a8068000
>>> [1548779.207596] RIP: 0010:[<ffffffffa04d9b0a>] [<ffffffffa04d9b0a>]
>>> __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.217209] RSP: 0018:ffff8801a806bba0 EFLAGS: 00010206
>>> [1548779.222879] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
>>> 0000000000000000
>>> [1548779.230543] RDX: ffffc90059d64000 RSI: ffffc90059f2efd0 RDI:
>>> 000000007f183000
>>> [1548779.238211] RBP: ffff8801a806bbc0 R08: ffff8801a806bd60 R09:
>>> 0000000000000100
>>> [1548779.245878] R10: 0000000000003649 R11: 0000000000000006 R12:
>>> ffff88027a7f0000
>>> [1548779.253524] R13: ffffffffa04d9ac0 R14: ffff8801a806bfd8 R15:
>>> 0000000000000000
>>> [1548779.261125] FS: 00007f3dd6aff700(0000) GS:ffff883ffe3c0000(0000)
>>> knlGS:0000000000000000
>>> [1548779.269733] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [1548779.275795] CR2: 000000007f183000 CR3: 00000001f50ab000 CR4:
>>> 00000000003427e0
>>> [1548779.283444] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>> 0000000000000000
>>> [1548779.291040] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
>>> 0000000000000400
>>> [1548779.298689] Stack:
>>> [1548779.301045] 0000000000000000 0000000000000297 0000000009b989ac
>>> 0000000000000000
>>> [1548779.309033] ffff8801a806bc48 ffffffffa04d9206 00ff8801a806bd10
>>> ffff8801a806bd60
>>> [1548779.317023] 0000000000000100 00000000000bffff 0000000100000001
>>> 00000000000396fa
>>> [1548779.325012] Call Trace:
>>> [1548779.327856] [<ffffffffa04d9206>] slot_handle_level_range+0x76/0x100 [kvm]
>>> [1548779.335090] [<ffffffffa04dac34>] kvm_mmu_slot_leaf_clear_dirty+0x54/0x80
>>> [kvm]
>>> [1548779.342922] [<ffffffffa03f8967>] vmx_slot_enable_log_dirty+0x17/0x30
>>> [kvm_intel]
>>> [1548779.350943] [<ffffffffa04d5d2f>] kvm_arch_commit_memory_region+0x5f/0xe0
>>> [kvm]
>>> [1548779.358776] [<ffffffffa04be7c5>] __kvm_set_memory_region+0x665/0xa90 [kvm]
>>> [1548779.366099] [<ffffffffa04be160>] ? kvm_kvzalloc+0x30/0x30 [kvm]
>>> [1548779.372457] [<ffffffffa04bec1b>] kvm_set_memory_region+0x2b/0x40 [kvm]
>>> [1548779.379423] [<ffffffffa04bf084>] kvm_vm_ioctl+0x454/0x700 [kvm]
>>> [1548779.385777] [<ffffffff8112f083>] ? ftrace_ops_list_func+0x83/0x110
>>> [1548779.392406] [<ffffffffa04bec30>] ? kvm_set_memory_region+0x40/0x40 [kvm]
>>> [1548779.399538] [<ffffffff811fceb5>] do_vfs_ioctl+0x2e5/0x4c0
>>> [1548779.405340] [<ffffffff811fd131>] SyS_ioctl+0xa1/0xc0
>>> [1548779.410736] [<ffffffff81652809>] system_call_fastpath+0x16/0x1b
>>> [1548779.417086] Code: c0 48 85 ff 0f 84 8f 00 00 00 40 f6 c7 01 0f 84 a5 00
>>> 00 00 48 83 e7 fe c7 45 e8 00 00 00 00 48 89 7d e0 48 8b 3f 48 85 ff 74 6e
>>> <48> 8b 17 f6 c2 01 74 5d 48 8b 05 c7 40 04 00 48 89 d1 31 db 48
>>> [1548779.438015] RIP [<ffffffffa04d9b0a>] __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.445109] RSP <ffff8801a806bba0>
>>> [1548779.448915] CR2: 000000007f183000
>>> [1548779.453070] ---[ end trace d99f28b71290c64c ]---
>>> [1548779.523937] Kernel panic - not syncing: Fatal exception
>>> [1548779.523945] perf interrupt took too long (124114 > 17857), lowering
>>> kernel.perf_event_max_sample_rate to 7000
>>> [1548779.524826] perf interrupt took too long (123163 > 31250), lowering
>>> kernel.perf_event_max_sample_rate to 4000
>>> [1548779.525717] perf interrupt took too long (122216 > 62500), lowering
>>> kernel.perf_event_max_sample_rate to 2000
>>> [1548779.603824] die even has been record!
>>
>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: hangaohuai <hangaohuai@huawei.com>
To: Chris Friesen <chris.friesen@windriver.com>
Cc: herongguang.he@huawei.com,
"wangxin (U)" <wangxinxin.wang@huawei.com>,
fangying1@huawei.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
rkrcmar@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] kvm bug in __rmap_clear_dirty during live migration
Date: Mon, 13 Feb 2017 21:19:46 +0800 [thread overview]
Message-ID: <58A1B272.1000402@huawei.com> (raw)
In-Reply-To: <589DDC05.9010807@windriver.com>
Hi, Chris Friesen.
We notice that you can reliably trigger the BUG during the live-migration stress test, however we can't.
Could you descripe your test steps so that we can re-trigger the BUG and get more information about it ?
On 2017/2/10 23:28, Chris Friesen wrote:
>
> Well, not so much solved as worked around it.
>
> It seems that the problem only showed up on Broadwell, which made us wonder about something hardware specific.
>
> Setting "kvm-intel.eptad=0" in the kernel boot args seems to mask the problem for us.
>
> Chris
>
> On 02/10/2017 03:11 AM, Herongguang (Stephen) wrote:
>> Hi, Chris Friesen, did you solve the problem?
>>
>> On 2017/2/9 22:37, Herongguang (Stephen) wrote:
>>> Hi.
>>> I had a problem when I just repeatedly live migrate a vm between two compute
>>> nodes.
>>> The phenomenon was that the KVM module was crashed and then the host rebooted.
>>> However I cannot reliably trigger this BUG.
>>>
>>> The backtrace is the same as http://www.spinics.net/lists/kvm/msg138475.html.
>>>
>>> The crash is triggered when function __rmap_clear_dirty is invoked and an
>>> invalid page(0x000000007f183000) is visited.
>>> The value %rdi is 0x000000007f183000, which is obviously not a valid kernel
>>> pointer for x86_64.
>>> The assembly of __rmap_clear_dirty is:
>>> 0xffffffffa04d9ac0 <__rmap_clear_dirty>: callq 0xffffffff816543d0
>>> <ftrace_caller>
>>> 0xffffffffa04d9ac5 <__rmap_clear_dirty+5>: push %rbp
>>> 0xffffffffa04d9ac6 <__rmap_clear_dirty+6>: mov %rsp,%rbp
>>> 0xffffffffa04d9ac9 <__rmap_clear_dirty+9>: push %rbx
>>> 0xffffffffa04d9aca <__rmap_clear_dirty+10>: sub $0x18,%rsp
>>> 0xffffffffa04d9ace <__rmap_clear_dirty+14>: mov (%rsi),%rdi
>>> 0xffffffffa04d9ad1 <__rmap_clear_dirty+17>: mov %gs:0x28,%rax
>>> 0xffffffffa04d9ada <__rmap_clear_dirty+26>: mov %rax,-0x10(%rbp)
>>> 0xffffffffa04d9ade <__rmap_clear_dirty+30>: xor %eax,%eax
>>> 0xffffffffa04d9ae0 <__rmap_clear_dirty+32>: test %rdi,%rdi
>>> 0xffffffffa04d9ae3 <__rmap_clear_dirty+35>: je 0xffffffffa04d9b78
>>> 0xffffffffa04d9ae9 <__rmap_clear_dirty+41>: test $0x1,%dil
>>> 0xffffffffa04d9aed <__rmap_clear_dirty+45>: je 0xffffffffa04d9b98
>>> 0xffffffffa04d9af3 <__rmap_clear_dirty+51>: and $0xfffffffffffffffe,%rdi
>>> 0xffffffffa04d9af7 <__rmap_clear_dirty+55>: movl $0x0,-0x18(%rbp)
>>> 0xffffffffa04d9afe <__rmap_clear_dirty+62>: mov %rdi,-0x20(%rbp)
>>> 0xffffffffa04d9b02 <__rmap_clear_dirty+66>: mov (%rdi),%rdi
>>> 0xffffffffa04d9b05 <__rmap_clear_dirty+69>: test %rdi,%rdi
>>> ...
>>>
>>> The details of the environment is:
>>> Host info: x86_64 CentOS 7 kernel (3.10.0-327.36.58.10_2.x86_64, slightly
>>> modified). The CPU is Broadwell Intel(R) Xeon(R) CPU E5-2618L v4 @ 2.20GHz.
>>> Kmod info: version is 4.4.36
>>> What I know is that the parameter PML(Page Modification Logging) is enabled by
>>> default.
>>> # cat /sys/module/kvm_intel/parameters/pml
>>> # Y
>>>
>>> Below is the crash message:
>>> [1548777.924180] kvm: zapping shadow pages for mmio generation wraparound
>>> [1548777.947844] HTB: quantum of class 10001 is big. Consider r2q change.
>>> [1548778.185389] kvm: zapping shadow pages for mmio generation wraparound
>>> [1548778.994801] BUG: unable to handle kernel paging request at 000000007f183000
>>> [1548779.002135] IP: [<ffffffffa04d9b0a>] __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.009151] PGD 1f8452067 PUD 0
>>> [1548779.012774] Thread overran stack, or stack corrupted
>>> [1548779.018076] Oops: 0000 [#1] SMP
>>> [1548779.027050] collected_len = 1048570, LOG_BUF_LEN_LOCAL = 1048576
>>> [1548779.042039] kbox: no notify die func register. no need to notify
>>> [1548779.048392] do nothing after die!
>>> [1548779.052071] Modules linked in: kboxdriver(O) kbox(O) sch_htb
>>> ip_set_hash_net ip6table_filter ip6_tables iptable_filter igb_uio(OE) uio
>>> bridge dm_service_time dm_multipath iscsi_tcp libiscsi_tcp libiscsi
>>> scsi_transport_iscsi 8021q garp stp mrp llc vfat fat isofs ext4 jbd2 xfs
>>> sha512_generic dev_connlimit(O) bum(O) ip_set nfnetlink prio(O) nat(O)
>>> vport_vxlan(O) openvswitch(O) nf_defrag_ipv6 gre ib_uverbs(OVE) hotpatch(OE)
>>> sigma_serial(O) pmcint(O) guest_kbox_ram(O) signo_catch(O) mlx4_ib(OVE)
>>> mlx4_en(OVE) vxlan ip6_udp_tunnel udp_tunnel ib_sa(OVE) ib_mad(OVE) ptp
>>> ib_core(OVE) ib_addr(OVE) pps_core ib_netlink(OVE) intel_powerclamp coretemp
>>> intel_rapl crc32_pclmul crc32c_intel ipmi_devintf(OVE) ghash_clmulni_intel
>>> mlx4_core(OVE) aesni_intel kvm_intel(O) igb(OVE) lrw gf128mul i2c_algo_bit
>>> glue_helper
>>> [1548779.125577] iTCO_wdt ablk_helper kvm(O) iTCO_vendor_support sg cryptd
>>> compat(OVE) dca sb_edac i2c_i801 kbox_pci(OVE) i2c_core edac_core pcspkr
>>> lpc_ich shpchp mfd_core ipmi_si(OVE) ipmi_msghandler(OVE) nf_conntrack_ipv4
>>> nf_defrag_ipv4 vhost_net(O) tun(O) vhost(O) macvtap macvlan vfio_pci irqbypass
>>> vfio_iommu_type1 vfio xt_sctp nf_conntrack_proto_sctp nf_nat_proto_sctp nf_nat
>>> nf_conntrack sctp libcrc32c ip_tables ext3 mbcache jbd sd_mod crc_t10dif
>>> crct10dif_generic ahci crct10dif_pclmul crct10dif_common libahci mpt2sas(OVE)
>>> libata raid_class scsi_transport_sas dm_mod [last unloaded: kbox]
>>> [1548779.178704] CPU: 35 PID: 33769 Comm: migration Tainted: G OE
>>> ----V------- 3.10.0-327.36.58.10_2.x86_64 #1
>>> [1548779.189855] Hardware name: HUAWEI TECHNOLOGIES CO.,LTD.
>>> CH80GPUB8/CH80GPUB8, BIOS GPUBV201 06/18/2015
>>> [1548779.199585] task: ffff880123da0000 ti: ffff8801a8068000 task.ti:
>>> ffff8801a8068000
>>> [1548779.207596] RIP: 0010:[<ffffffffa04d9b0a>] [<ffffffffa04d9b0a>]
>>> __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.217209] RSP: 0018:ffff8801a806bba0 EFLAGS: 00010206
>>> [1548779.222879] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
>>> 0000000000000000
>>> [1548779.230543] RDX: ffffc90059d64000 RSI: ffffc90059f2efd0 RDI:
>>> 000000007f183000
>>> [1548779.238211] RBP: ffff8801a806bbc0 R08: ffff8801a806bd60 R09:
>>> 0000000000000100
>>> [1548779.245878] R10: 0000000000003649 R11: 0000000000000006 R12:
>>> ffff88027a7f0000
>>> [1548779.253524] R13: ffffffffa04d9ac0 R14: ffff8801a806bfd8 R15:
>>> 0000000000000000
>>> [1548779.261125] FS: 00007f3dd6aff700(0000) GS:ffff883ffe3c0000(0000)
>>> knlGS:0000000000000000
>>> [1548779.269733] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [1548779.275795] CR2: 000000007f183000 CR3: 00000001f50ab000 CR4:
>>> 00000000003427e0
>>> [1548779.283444] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>>> 0000000000000000
>>> [1548779.291040] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
>>> 0000000000000400
>>> [1548779.298689] Stack:
>>> [1548779.301045] 0000000000000000 0000000000000297 0000000009b989ac
>>> 0000000000000000
>>> [1548779.309033] ffff8801a806bc48 ffffffffa04d9206 00ff8801a806bd10
>>> ffff8801a806bd60
>>> [1548779.317023] 0000000000000100 00000000000bffff 0000000100000001
>>> 00000000000396fa
>>> [1548779.325012] Call Trace:
>>> [1548779.327856] [<ffffffffa04d9206>] slot_handle_level_range+0x76/0x100 [kvm]
>>> [1548779.335090] [<ffffffffa04dac34>] kvm_mmu_slot_leaf_clear_dirty+0x54/0x80
>>> [kvm]
>>> [1548779.342922] [<ffffffffa03f8967>] vmx_slot_enable_log_dirty+0x17/0x30
>>> [kvm_intel]
>>> [1548779.350943] [<ffffffffa04d5d2f>] kvm_arch_commit_memory_region+0x5f/0xe0
>>> [kvm]
>>> [1548779.358776] [<ffffffffa04be7c5>] __kvm_set_memory_region+0x665/0xa90 [kvm]
>>> [1548779.366099] [<ffffffffa04be160>] ? kvm_kvzalloc+0x30/0x30 [kvm]
>>> [1548779.372457] [<ffffffffa04bec1b>] kvm_set_memory_region+0x2b/0x40 [kvm]
>>> [1548779.379423] [<ffffffffa04bf084>] kvm_vm_ioctl+0x454/0x700 [kvm]
>>> [1548779.385777] [<ffffffff8112f083>] ? ftrace_ops_list_func+0x83/0x110
>>> [1548779.392406] [<ffffffffa04bec30>] ? kvm_set_memory_region+0x40/0x40 [kvm]
>>> [1548779.399538] [<ffffffff811fceb5>] do_vfs_ioctl+0x2e5/0x4c0
>>> [1548779.405340] [<ffffffff811fd131>] SyS_ioctl+0xa1/0xc0
>>> [1548779.410736] [<ffffffff81652809>] system_call_fastpath+0x16/0x1b
>>> [1548779.417086] Code: c0 48 85 ff 0f 84 8f 00 00 00 40 f6 c7 01 0f 84 a5 00
>>> 00 00 48 83 e7 fe c7 45 e8 00 00 00 00 48 89 7d e0 48 8b 3f 48 85 ff 74 6e
>>> <48> 8b 17 f6 c2 01 74 5d 48 8b 05 c7 40 04 00 48 89 d1 31 db 48
>>> [1548779.438015] RIP [<ffffffffa04d9b0a>] __rmap_clear_dirty+0x4a/0xf0 [kvm]
>>> [1548779.445109] RSP <ffff8801a806bba0>
>>> [1548779.448915] CR2: 000000007f183000
>>> [1548779.453070] ---[ end trace d99f28b71290c64c ]---
>>> [1548779.523937] Kernel panic - not syncing: Fatal exception
>>> [1548779.523945] perf interrupt took too long (124114 > 17857), lowering
>>> kernel.perf_event_max_sample_rate to 7000
>>> [1548779.524826] perf interrupt took too long (123163 > 31250), lowering
>>> kernel.perf_event_max_sample_rate to 4000
>>> [1548779.525717] perf interrupt took too long (122216 > 62500), lowering
>>> kernel.perf_event_max_sample_rate to 2000
>>> [1548779.603824] die even has been record!
>>
>
>
>
> .
>
next prev parent reply other threads:[~2017-02-13 13:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 14:37 kvm bug in __rmap_clear_dirty during live migration Herongguang (Stephen)
2017-02-09 14:37 ` [Qemu-devel] " Herongguang (Stephen)
2017-02-10 8:50 ` Herongguang (Stephen)
2017-02-10 8:50 ` [Qemu-devel] " Herongguang (Stephen)
2017-02-10 9:11 ` Herongguang (Stephen)
2017-02-10 9:11 ` [Qemu-devel] " Herongguang (Stephen)
2017-02-10 15:28 ` Chris Friesen
2017-02-10 15:28 ` [Qemu-devel] " Chris Friesen
2017-02-10 16:14 ` Paolo Bonzini
2017-02-10 16:14 ` [Qemu-devel] " Paolo Bonzini
2017-02-13 13:19 ` hangaohuai [this message]
2017-02-13 13:19 ` hangaohuai
2017-02-20 2:17 ` hangaohuai
2017-02-20 2:17 ` [Qemu-devel] " hangaohuai
2017-02-20 4:38 ` Han, Huaitong
2017-02-22 3:08 ` Chris Friesen
2017-02-22 11:15 ` Paolo Bonzini
2017-02-22 13:31 ` Chris Friesen
2017-02-22 14:43 ` Paolo Bonzini
2017-02-24 2:23 ` Herongguang (Stephen)
2017-02-24 2:23 ` Herongguang (Stephen)
2017-02-24 9:35 ` Herongguang (Stephen)
2017-02-24 9:35 ` Herongguang (Stephen)
2017-02-24 9:59 ` Greg KH
2017-02-24 10:00 ` Paolo Bonzini
2017-02-24 10:07 ` Greg KH
2017-02-24 10:07 ` [Qemu-devel] " Greg KH
2017-02-24 15:10 ` Chris Friesen
2017-02-24 15:10 ` Chris Friesen
2017-02-24 15:14 ` Paolo Bonzini
2017-02-24 15:14 ` [Qemu-devel] " Paolo Bonzini
2017-02-25 1:44 ` Herongguang (Stephen)
2017-02-25 1:44 ` Herongguang (Stephen)
2017-02-27 7:38 ` Huang, Kai
2017-02-27 7:38 ` [Qemu-devel] " Huang, Kai
2017-03-13 14:58 ` fangying
2017-03-13 14:58 ` fangying
2017-03-13 16:57 ` Paolo Bonzini
2017-03-16 1:40 ` Huang, Kai
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=58A1B272.1000402@huawei.com \
--to=hangaohuai@huawei.com \
--cc=chris.friesen@windriver.com \
--cc=fangying1@huawei.com \
--cc=herongguang.he@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkrcmar@redhat.com \
--cc=wangxinxin.wang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.