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

["Langsdorf, Mark" <mark.langsdorf@xxxxxxx>]

> > > Yes, and that is already done, hooked off the cpu notifier
> > > callback chain. Nobbling the C- and P-state logic
< shouldn't be necessary.
> > 
> > And yet, people are still reporting "Time went backwards"
> > messages upwards of 30-40 times an hour on RevF Opterons
> > when PowerNow! is enabled on Xen.
> > 
> > I spent a month trying to debug this and I made no significant
> > progress.  If someone who understands Xen timekeeping wants to
> > help me dive into this, I'll be glad to take another stab at
> > it.  As it is, even with informing Xen of frequency changes,
> > Xen does not ensure monotinicity.
> 
> I do think we need to understand what's going on here.
> 
> 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
cpu_processed=2994400167600
> Jan 19 00:11:09 server kernel:  0: 2994400167600
> Jan 19 00:11:09 server kernel:  1: 2994213786880
> Jan 19 00:11:09 server kernel: Timer ISR/1: Time went backwards:
> delta=-50043804 delta_cpu=136336916 shadow=29
> 93571302800 off=778821372 processed=2994400167600
cpu_processed=2994213786880
> Jan 19 00:11:09 server kernel:  0: 2994400167600
> Jan 19 00:11:09 server kernel:  1: 2994213786880
> Jan 19 00:11:09 server kernel: Timer ISR/1: Time went backwards:
> delta=-70033718 delta_cpu=66347002 shadow=299
> 3571302800 off=838831281 processed=2994480167600
cpu_processed=2994343786880
> Jan 19 00:11:09 server kernel:  0: 2994480167600
> Jan 19 00:11:09 server kernel:  1: 2994343786880
>
> This happens also if I switch manually with
> cpufreq-set -f 2.60GHz of cpufrequtils.

It seems to happen most reliably when there's a large jump in
frequency (2.6 GHz to 800 MHz or vice versa) but I've seen it
happen for smaller switches.  Usually there's 1 large backward
movement, and then 2-4 smaller ones.  It doesn't always happen,
especially if there are multiple shifts in a short period (ie,
constant changes on the ondemand governor) and it seems to 
happen more consistently when increasing frequency.

> Are you sure the systems aren't overheating and performing emergency
> T-state thermal throttling?  

Yes.  The same machine that instantly has time going backwards
after a pstate change can stay at that pstate for hours without
any time issues, whether its a low pstate or a high pstate.

-Mark Langsdorf
Operating System Research Center
AMD



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel