|
From: | Gerhard Wiesinger |
Subject: | Re: [Qemu-devel] Fedora FC21 - Bug: 100% CPU and hangs in gettimeofday(&tp, NULL); forever |
Date: | Tue, 13 Jan 2015 22:14:40 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
On 13.01.2015 21:48, Paolo Bonzini wrote:
On 13/01/2015 21:13, Gerhard Wiesinger wrote: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? Any further ideas?Hmm, too bad. :( Any chance you can try with 1.7 and 2.0 releases? Cole, perhaps you help building some RPMS for Gerhard?
Yes, I can try. RPMs would be fine.Don't know if it is related, but on another VM maschine I was getting the following 75s after reboot: [ 78.857006] INFO: rcu_sched self-detected stall on CPU { 0} (t=60000 jiffies g=1966 c=1965 q=0) [ 258.860006] INFO: rcu_sched self-detected stall on CPU { 0} (t=240003 jiffies g=1966 c=1965 q=0)
I also had a look at the kernel code again: http://lxr.free-electrons.com/source/kernel/time/timekeeping.c?v=3.17#L493 499 do { 500 seq = read_seqcount_begin(&tk_core.seq); 501 502 ts->tv_sec = tk->xtime_sec; 503 nsecs = timekeeping_get_ns(&tk->tkr); 504 505 } while (read_seqcount_retry(&tk_core.seq, seq));So it looks like that the seqcount always changes and therefore loops forever here (as far as I digged it down this is the only loop here).
Might be something wrong with the memory barriers in recent qemu-kvm releases?
Ciao, Gerhard
[Prev in Thread] | Current Thread | [Next in Thread] |