Re: [Xen-devel] [Xen-users] Re: Xen 4 TSC problems

[Keir Fraser <keir@xxxxxxx>]

On 15/10/2012 15:25, "Mauro" <mrsanna1@xxxxxxxxx> wrote:

> On 15 October 2012 14:49, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 15.10.12 at 13:24, Mauro <mrsanna1@xxxxxxxxx> wrote:
>>> I have the problem on this hardware type:
>>> 
>>> Hp Proliant DL580 G5 with four Intel(R) Xeon(R) CPU E7330  @ 2.40GHz.
>>> It seem that
>>> GRUB_CMDLINE_XEN="clocksource=pit cpuidle=0"
>>> put in in /etc/default/grup (I use linux debian)
>>> solves the problem for me.
>> 
>> Did you check whether either or both options on their own also
>> make the problem go away?
> 
> Only clocksource=pit does not solve the problem, I've not tried with
> only cpuidle=0, I will try soon.

The problem here is that the platform timer has *not* wrapped. In fact it is
almost certainly correct, and it is the calculation of current-system-time
extrapolated from local CPU's TSC that has gone haywire. The
overflow-handling logic in plt_overflow() then propagates that incorrectness
into plt_stamp64 (up to a maximum of 10 times wrapping the platform timer's
counter). This means that platform time is incorrect (skips forward) and
soon after will infect the local time estimation for all CPUs.

I've attached a patch which will (a) stop plt_overflow() from misguidedly
trying to fix up apparent platform timer overflow; and (b) will print
possibly-useful diagnostics when apparent 'timer overflow' occurs. Such
lines will be prefixed "XXX plt_overflow:" in the hypervisor log. Patch is
against xen-unstable but I'm sure it must backport to older trees quite
trivially.

 -- Keir

Attachment: 00-tsc-debug
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel