Another finding: it seems as if - when munin starts - there is a
transition directly from
1.0 GHz towards 2.1 GHz. At least I see only one transition state
counted up and ticks on
2.1 GHz in cpufreq-stats. Hmmm. Is that right?
BR,
Carsten.
-----Ursprüngliche Nachricht-----
Von: Carsten Schiers
Gesendet: Samstag, 7. März 2009 23:13
An: xen-devel
Cc: mark.langsdorf; keir.fraser
Betreff: AW: [Xen-devel] Still Time went backwards problems Xen
3.3.1/2.6.18.8
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home