[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

  • To: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Wed, 23 Jan 2008 22:34:54 +0000
  • Delivery-date: Wed, 23 Jan 2008 14:35:32 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AchdJLibYAsM6tf0TQmN0NytQtkgrAAFoN6AAAFwnhMAJGZRIAAK2VqAAAAk5aAABGbw7A==
  • Thread-topic: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors

On 23/1/08 21:34, "Langsdorf, Mark" <mark.langsdorf@xxxxxxx> wrote:

>> Are the 'time went backwards' messages correlated with power
>> management operations?
> Yes, I can regularly generate messages by switching the governor
> from powersave (minimum frequency) to performance (maximum
> frequency).
>> How far is time stepping backwards?
>> ns, us, or ms? 
> Rolf's message is typical:
>> Jan 19 00:11:09 server kernel: printk: 14 messages suppressed.
>> Jan 19 00:11:09 server kernel: Timer ISR/0: Time went backwards:
>> delta=-123862858 delta_cpu=-123862858 shadow=
>> 2993571302800 off=705014593 processed=2994400167600

That's a big deviation. I suggest adding tracing to xen/arch/x86/time.c. In
cpu_frequency_change() and local_time_calibration(), where we get_s_time()
and read_platform_stime() it is worth checking if those two values differ by
more than a few milliseconds and print a (platform timestamped) message if
so. Perhaps we can work out if the deviation from wall time is occurring
when the cpu frequency change occurs, or is creeping up over the next epoch
or two (e.g., because the frequency notified to Xen by dom0 is inaccurate?).

 -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.