Re: 2.6.35-rc1 regression with pvclock and smp guests

[Avi Kivity <avi@redhat.com>]

  On 07/27/2010 04:48 PM, Andre Przywara wrote:
>> Wierd.  Maybe the clock goes crazy.
>>
>> Let's see if it jumps forward alot:
>>
>>          } while (unlikely(last != ret));
>> +
>> +       {
>> +            static u64 last_report;
>> +            if (ret > last_report + 10000) {
>> +                    last_report = ret;
>> +                    printk("kvmclock: %llx\n", ret);
>> +            }
>> +
>> +       }
>>
>>          return ret;
>>   }
>>
>> Worth updating the 'return last' to update ret and goto the new code, 
>> so we don't miss that path.
>
> Did that. There is _a lot_ of output (about 350 lines per second via 
> the 115k serial console), both with smp=1 and smp=2.
> The majority is differing about 2,000,000 (ticks?), but a handful of 
> them are in the range of 20 million. 

nanoseconds.  So 2-20ms.  Consistent with 350 lines/sec.

> No difference between smp=2 and smp=1.
> I also get some "BUG: recent printk recursion!" and I don't see any 
> kernel boot progress beyond outputting the BogoMIPS value.

Right, printk() wants the time too.

> BTW: I found two message from your earlier debug statement:
> [    0.000000] kvm-clock: cpu 0, msr 0:1ac0401, boot clock
> [    0.000000] kvm-clock: cpu 0, msr 0:1e15401, primary cpu clock

Those are from kvmclock initialization, not from the older patch.

I'm completely confused, everything seems to be in order.

Let's see.  if you s/return last/return ret/ in the original, does this 
help things along?  this makes pvclock drop the computation and should 
be exactly the same as before the patch.

-- 
error compiling committee.c: too many arguments to function