From: Dominik Brodowski <linux@dominikbrodowski.de>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: davej@redhat.com, cpufreq list <cpufreq@www.linux.org.uk>
Subject: Re: [PATCH] speedstep-centrino: Avoid returning zero freq on transient MSR values
Date: Fri, 10 Dec 2004 15:47:55 +0100 [thread overview]
Message-ID: <20041210144754.GA8259@dominikbrodowski.de> (raw)
In-Reply-To: <1102673495.18051.9.camel@minilith.goop.org>
On Fri, Dec 10, 2004 at 02:11:35AM -0800, Jeremy Fitzhardinge wrote:
> On Thu, 2004-12-09 at 17:24 -0800, Venkatesh Pallipadi wrote:
> >
> >
> > On some CPUs, we can see transient MSR values (which are not present in _PSS) in
> > IA32_PERF_STATUS MSR, while CPU is doing some automatic P-state transition
> > (like TM2).
> > Current code will return frequency as 0 in such cases. Fix it by retrying the
> > get after a delay and use lowest possible frequency as the current frequency
> > in worst case.
> >
> > Thanks to Matt Domsch for identifying and root-causing this failure.
>
> Doesn't this suggest there's a more subtle problem? If the CPU is
> changing speeds autonomously, then it means the TSC calibration will be
> broken. Is there some way of finding out about these transitions?
The TSC runs at a fixed frequency on these CPUs [Venki will submit a patch
for that soon], so it isn't a problem for the kernel AFAICS.
> Also, why not just report the actual MSR frequency, rather than looking
> for a table/_PSS match? Are the MSR values meaningfully encoded?
AFAIK, the encoding may be very chip specific.
Thanks,
Dominik
next prev parent reply other threads:[~2004-12-10 14:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-10 1:24 [PATCH] speedstep-centrino: Avoid returning zero freq on transient MSR values Venkatesh Pallipadi
2004-12-10 8:14 ` Dominik Brodowski
2004-12-10 10:11 ` Jeremy Fitzhardinge
2004-12-10 14:47 ` Dominik Brodowski [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-12-10 18:37 Pallipadi, Venkatesh
2004-12-10 21:16 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041210144754.GA8259@dominikbrodowski.de \
--to=linux@dominikbrodowski.de \
--cc=cpufreq@www.linux.org.uk \
--cc=davej@redhat.com \
--cc=jeremy@goop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.