On 21/11/2014 07:30, Wanpeng Li wrote:
> I test it on the other guy's Ivytown and take advantage of the qemu command
> line which he used, so I forget the accurate command line which used that day.
>
> Paolo also reproduce the bug, Paolo, ping.
It also reproduced always for me with a debug ker
Hi Tang,
On Fri, Nov 21, 2014 at 02:41:57PM +0800, Tang Chen wrote:
>Hi Wanpeng,
>
>Sorry, it is about this problem again.
>
>I booted 3.18.0-rc2, without Paolo's patch. lockdep and RCU debug
>were all opened.
>
>Then I started a qemu vm with the following options:
>
>/usr/libexec/qemu-kvm -hda rhe
Thanks for the sharing. Will do more tests. :)
On 11/14/2014 07:39 AM, Wanpeng Li wrote:
Hi Tang,
On Tue, Nov 11, 2014 at 01:35:29PM +0800, Tang Chen wrote:
Hi Wanpeng,
Sorry for the late.
I think I have totally missed this thread.
I opened lockdep and RCU debug, and tried on 3.18-rc1. But
Hi Tang,
On Tue, Nov 11, 2014 at 01:35:29PM +0800, Tang Chen wrote:
>Hi Wanpeng,
>
Sorry for the late.
>I think I have totally missed this thread.
>I opened lockdep and RCU debug, and tried on 3.18-rc1. But I didn't
>get the warning.
I also opened lockdep and RCU debug, and tried 3.18.0-rc2 on a
Hi Wanpeng,
I think I have totally missed this thread.
I opened lockdep and RCU debug, and tried on 3.18-rc1. But I didn't get
the warning.
My steps are:
1. Use numactl to bind a qemu process to node1.
2. Offline all node1 memory. And the qemu process is still running.
Would you please tell m
The srcu read lock must be held while accessing memslots (e.g.
when using gfn_to_* functions), however, commit c24ae0dcd3e8
("kvm: x86: Unpin and remove kvm_arch->apic_access_page") call
gfn_to_page() in kvm_vcpu_reload_apic_access_page() w/o hold it in
vmx_vcpu_reset() path which leads to suspici
