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

[Gerhard Wiesinger]

On 13.01.2015 22:16, Paolo Bonzini wrote:
> On 13/01/2015 22:14, Gerhard Wiesinger wrote:
> > 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?
> No, that's not possible.  Unless you pause/resume or migrate the VM, all
> of the handling of kvmclock is entirely in the kernel.

Any other possible explaination of the problem?

Had a look at the diff (I guess the right file at least in qemu tree):
# no critical changes IHMO here
git diff -u v1.6.2..v2.1.2 ./hw/i386/kvm/clock.c

Trying to reproduce with a loop:
#include <sys/time.h>
#include <stdio.h>

int main(int argc, char* argv[])
{
  struct timeval tv;
  int i = 0;
  for (;;)
  {
    gettimeofday(&tv, 0);
    ++i;
    if (i >= 10000000)
    {
      i = 0;
      printf("%i\n", (int)tv.tv_sec);
    }
  }
  return 0;
}

As I wrote this: "First tests seem to run well, so no quick win ....", I 
could reproduce it with a stall in 318s :-)
(gdb) bt
#0  0x00007fff6d9fefff in gettimeofday ()
#1  0x00000000004005ad in main (argc=1, argv=0x7fff6d9b28b8) at 
gettimeofdayloop.c:10

So we have at least a testcase which is quickly to reproduce.

So we are digging down my second findings about a major bug in qemu-kvm  :-)

Can someone try, too?

Ciao,
Gerhard