Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever

[Juan Quintela <quintela@redhat.com>]

Juan Quintela <quintela@redhat.com> wrote:
> Gerhard Wiesinger <lists@wiesinger.com> wrote:
>> On 12.01.2015 12:41, Gerhard Wiesinger wrote:
>>> On 08.01.2015 23:28, Gerhard Wiesinger wrote:
>>>>
>>>> I'll keep you up to date in the next days whether it happens again
>>>> or not.
>>>
>>> With qemu-kvm 2.2.0 release from the above repository the 100% usage
>>> didn't happen so far (although I had to reboot after kernel update).
>>
>> It happens also with qemu-kvm 2.2.0 on another VM where also
>> PostgreSQL is running:
>> (gdb) bt
>> #0  0x00007fff9a1feff4 in gettimeofday ()
>> #1  0x00000000006d425e in GetCurrentTimestamp () at timestamp.c:1274
>>
>> What we know:
>> OK : F20: 3.17.6-200.fc20.x86_64 on guest/host,
>> qemu-kvm-1.6.2-10.fc20.x86_64 on host
>> NOK: F21: 3.17.7-300.fc21.x86_64 on guest/host,
>> qemu-kvm-2.1.2-7.fc21.x86_64 on host
>> NOK: F21: 3.17.8-300.fc21.x86_64 on guest/host,
>> qemu-kvm-2.2.0-1.fc21.x86_64 on host
>>
>> No one less can reproduce or has similar problems?
>
> I have similar problems, F21 guest on F21 host.
> https://bugzilla.redhat.com/show_bug.cgi?id=1174664
>
> For me, it is firefox that from time to time loops on vclock_gettime().
> At that point the DSO have got corrupted (kvmclock msr's), and as you
> say, only solution is reboot.  Could you look at the bug, and see if the
> areas pointed by the MSR also got corrupted?  I tried using kernel-debug
> with debugging for memory allocation (marcelo request).  I see pattens
> like 0x5a5a5a5a, so clearly there is some corruption, but haven't been
> able to find _what_ is making that happen.
>
>> Any further ideas?
>
> Nope :-(
>
>> BTW: I'm running ntp in the following manner: internet <=> ntp server
>> in VM <=> ntp client on KVM host (firewall runs in KVM)
>
> I am uisng ntp on the host against Internet, but the guest don't use ntp
> (I do a ntpdate if I see that the guest has drifted too much, and it is
> a rare event.  Right now I don't rememeber having fixed it lately).

I forgot tell on the previous patch, I am using 2vcpus.  with a single
vcpu I have been unable to trigger this bug.

Later, Juan.