WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

AW: [Xen-devel] Still Time went backwards problems Xen 3.3.1/2.6.18.8

To: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: AW: [Xen-devel] Still Time went backwards problems Xen 3.3.1/2.6.18.8
From: "Carsten Schiers" <carsten@xxxxxxxxxx>
Date: Sat, 7 Mar 2009 23:13:14 +0100
Cc: "mark.langsdorf" <mark.langsdorf@xxxxxxx>, "keir.fraser" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Sat, 07 Mar 2009 14:14:06 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <H0000067000215fb.1236418906.uhura.space.zz@MHS>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Leaving out cpuidle doesn't make any difference:

  Mar  7 22:45:04 data kernel: Timer ISR/0: Time went backwards: 
delta=-23283686 ...

I think unstable is going to got frozen soon. I guess this is next to 
try. 

BTW: again three seconds after munin-cron.

BR,
Carsten.
 
-----Ursprüngliche Nachricht-----
Von: Carsten Schiers 
Gesendet: Samstag, 7. März 2009 10:42
An: xen-devel
Cc: mark.langsdorf; keir.fraser
Betreff: [Xen-devel] Still Time went backwards problems Xen 
3.3.1/2.6.18.8

Still have problems with "Time went backwards" messages. Now I am nearly 
completely at Xen 3.3.1 and Xen kernel 2.6.18.8 for Dom0 and nearly all 
DomUs. There is only one DomU That is on a customized special kernel for 
Endian (2.6.21.7-2).

Q1: Can a DomU kernel version anyhow be responsible for that effect?

Attached you can see the last two days. I noticed that they occur every 
five minutes, so it's probably connected with the munin cron job that 
collects xen domain usage and cpufreq-stats. Nothing more. Delta is 
still quite huge, around 40 ms. 
Value is negative.

Q2: Is that any better than if it's positive?
Q3: Will the delta be reset or will it go up and down all the time?

Currently I use both cpufreq=dom0 and cpuidle. 

Q4: Can the problem eventually be related to either of them only?

Right now, I disabled cpuidle for the time being, to see whether there 
is a difference.
If not, I intend to use xen-unstable next. I attached the current xm 
dmesg and xm info, so don't be surprised to miss cpuidle.

Well, I am not sure whether I do too much work on this issue, but I 
think the log message is there for a reason. 

Best Regards,
Carsten.

P.S.: There are combinations that are much worse that this. Especially 
running Xen 3.3.1 and actual Lenny kernel seems to be worse.

-----Ursprüngliche Nachricht-----
Von: Langsdorf, Mark [mailto:mark.langsdorf@xxxxxxx]
Gesendet: Donnerstag, 15. Januar 2009 20:27
An: Carsten Schiers
Betreff: RE: RE: RE: RE: [Xen-devel] AMD P-States not recognized for Xen
3.3 and 3.4

If you have a single socket system, then fixing the out of sync issue 
will probably not fix the TSC issue.

If you have a dual or quad socket system, fixing the out of sync error 
should reduce the frequency and magnitude of the TSC issues.  At least, 
that's the best I can decipher from my notes.

Also, most of the work I did on cpufreq was in 2007, before Dan M. 
greatly redid Xen hypervisor time-keeping.
If an up-to-date kernel/hypervisor still has TSC problems, it may be 
possible to fix them.  I don't really have time to research it myself, 
but if you do have problems, please contact me and I'll see what can be 
done.

-Mark Langsdorf
Operating System Research Center
AMD

> -----Original Message-----
> From: Carsten Schiers [mailto:carsten@xxxxxxxxxx]
> Sent: Thursday, January 15, 2009 1:17 PM
> To: Langsdorf, Mark
> Subject: AW: RE: RE: RE: [Xen-devel] AMD P-States not recognized for 
> Xen 3.3 and 3.4
> 
> Thanks Mark, don't want to get on your nerve, but this will only fix 
> the
> powernow-k8 out of synch issue but not the fact that my 4050e will 
> have TSC issues between the two cores when switching frequencies, 
> right?
> 
> Am I right that there is no cure for that currently? And that I am not 

> safe to ignore them, because some kernel wizard is synchronizing them? 

> 'Cause up to now I only found a synch in boot.c.
> 
> Sorry for all those questions, it's quite complicated. My best times 
> as code producer habe been some 15 years ago...
> 
> Thanks,
> Carsten.
> 
> -----Ursprüngliche Nachricht-----
> Von: Langsdorf, Mark [mailto:mark.langsdorf@xxxxxxx]
> Gesendet: Donnerstag, 15. Januar 2009 18:23
> An: Carsten Schiers
> Betreff: RE: RE: RE: [Xen-devel] AMD P-States not recognized for Xen 
> 3.3 and 3.4
> 
> > Thank you Mark. Please excuse my small knowledge in kernel/xen 
> > hacking.  I understood that I should either
> > 
> >   a) create a build of the actual xen-unstable.hg together with 
> > linux-2.6.18-xen.hg kernel (where you think to have fixed
> the problem)
> >
> > or
> > 
> >   b) to include the mentioned fixes into my environment
> (which is the
> > 3.2.1 Xen and Bastian Blank's (waldi) kernel (based on 2.6.18, too), 

> > right?
> > 
> > I'll try out what will be more easy, but I think it should be a).
> 
> Right.  Using the latest unstable kernel & hypervisor gives you all 
> the patches.  If you're backporting support into the waldi kernel, you 

> need to make sure you backport all the relevant patches.
> 
> -Mark Langsdorf
> Operating System Research Center
> AMD
> 
> 
> 
> 
> 






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

<Prev in Thread] Current Thread [Next in Thread>