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
>
>
>
>
>
log.txt
Description: Binary data
xmdmesg.txt
Description: Binary data
xminfo.txt
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|