Hello all,
We recently had Intel give our company a roadmap presentation where they
told us that their enhanced speedstep technology was supported by linux
kernels 2.6.9+. I have since tried to get cpufreq speedstep driver to
work with no luck on our em64t Xeon 3.6g processors. Intel even has a
webpage describing the technology and how to get it working at url:
http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
I made a bugzilla report to redhat [Bug 169290] and got a reply that
none of the Xeon's were supported yet on speedstep because they cannot
find documentation detailing the tables of frequencies these CPUs support.
The only processor I have had luck with so far is a 32-bit Xeon with the
p4-clockmod driver(which does not appear to be present in the x86-64
kernel).
Anyone have any knowledge regarding cpufreq and when the em64t's are
going have a linux driver supporting the speedstep technology? If it is
an issue of Intel not providing the neccessary info, maybe I can press
the issue with the gentlemen that came to my office and stated support
was there already.
Thanks for any info and advice. Please CC my on any replies since I am
not on the list.
Rich Wohlstadter
Genome Sequencing Center
Washington Univ. of St. Louis
Richard Wohlstadter wrote:
> Hello all,
>
> We recently had Intel give our company a roadmap presentation where they
> told us that their enhanced speedstep technology was supported by linux
> kernels 2.6.9+. I have since tried to get cpufreq speedstep driver to
> work with no luck on our em64t Xeon 3.6g processors. Intel even has a
> webpage describing the technology and how to get it working at url:
> http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
I think this is a BIOS problem; the BIOS needs to provide the proper
ACPI frequency/voltage tables for cpufreq to use. You might want to
harass your system/motherboard vendor.
Alternately maybe you can find someone who can give you the secret table
and then you can just hardcode it into the driver.
> The only processor I have had luck with so far is a 32-bit Xeon with the
> p4-clockmod driver(which does not appear to be present in the x86-64
> kernel).
Beware that p4-clockmod won't increase the power efficiency of your
system. (As an aside, clock modulation is so simple that you can do it
from userspace in a few lines of C if you modprobe msr. This works on
x86-64.)
Wes Felter - [email protected]
>-----Original Message-----
>From: Dave Jones [mailto:[email protected]]
>Sent: Friday, September 30, 2005 6:05 AM
>To: Pallipadi, Venkatesh
>Cc: Wes Felter; [email protected]
>Subject: Re: em64t speedstep technology not supported in kernel yet?
>
>On Fri, Sep 30, 2005 at 05:20:03AM -0700, Pallipadi, Venkatesh wrote:
> >
> > >-----Original Message-----
> > >From: [email protected]
> > >[mailto:[email protected]] On Behalf Of Wes Felter
> > >Sent: Thursday, September 29, 2005 11:58 AM
> > >To: [email protected]
> > >Subject: Re: em64t speedstep technology not supported in
>kernel yet?
> > >
> > >Richard Wohlstadter wrote:
> > >> Hello all,
> > >>
> > >> We recently had Intel give our company a roadmap
> > >presentation where they
> > >> told us that their enhanced speedstep technology was
> > >supported by linux
> > >> kernels 2.6.9+. I have since tried to get cpufreq speedstep
> > >driver to
> > >> work with no luck on our em64t Xeon 3.6g processors. Intel
> > >even has a
> > >> webpage describing the technology and how to get it
>working at url:
> > >>
>http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
> > >
> > >I think this is a BIOS problem; the BIOS needs to provide
>the proper
> > >ACPI frequency/voltage tables for cpufreq to use. You
>might want to
> > >harass your system/motherboard vendor.
> > >
> > >Alternately maybe you can find someone who can give you the
> > >secret table and then you can just hardcode it into the driver.
> >
> > Yes. Make sure speedstep is supported and enabled in BIOS.
>Typically,
> > there will be a BIOS config option under CPU section,
>called Speedstep,
> > Enhanced Speedstep or EIST or something like that.
>
>The BIOS tables make no difference at all however to the
>speedstep-centrino
>module (which in retrospect really should have been
>speedstep-est or something)
>as it has no OP() tables or cpu recognition for Xeons.
>
> Dave
Actually, speedstep-centrino works in two modes. One OP()
table based mode and the other ACPI table based mode. So,
BIOS ACPI tables do matter for the second mode and things
work without a static OP table.
Also, OP() table based modes is not really scalable as one
has to enter new tabled for every new model and also not
complete as it cannot take ACPI events (say different
P-states for battery or AC on laptop, which may not matter
that much for Xeon...). That's the reason we want to have
ACPI/BIOS based speedstep as much as possible. Of course
there will always be broken BIOSes which we have
to workaround....
In this particular case though, for Xeon with Enhanced Speedstep,
acpi-cpufreq should be the driver of choice as there is a need
for coordination of HT siblings, which happen in BIOS at the
moment with most BIOSes. That is the reason, I want to make
sure BIOS supports Enhanced Speedstep in this case.
Thanks,
Venki
On Fri, Sep 30, 2005 at 06:20:15AM -0700, Pallipadi, Venkatesh wrote:
> Actually, speedstep-centrino works in two modes. One OP()
> table based mode and the other ACPI table based mode. So,
> BIOS ACPI tables do matter for the second mode and things
> work without a static OP table.
True. Ack, I've spent too much time playing with that driver
and broken BIOS's lately, that I'd forgotten about this. :)
> In this particular case though, for Xeon with Enhanced Speedstep,
> acpi-cpufreq should be the driver of choice as there is a need
> for coordination of HT siblings, which happen in BIOS at the
> moment with most BIOSes. That is the reason, I want to make
> sure BIOS supports Enhanced Speedstep in this case.
Ok, that makes sense.
Dave