Shuttle K48 and speedstep.

Shuttle K48 and speedstep.

[Rasmus Wiman]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

Hi everybody,

a few months ago I bought myself a Shuttle K48 to use with Vortexbox as
a media PC. I put in an old Intel Pentium dual-core E2140 that I had
lying around. However, even after getting a better fan I still found it
a bit on the noisy side, so I decided to try a 45ns cpu and got a dual
core E5300. Better, but now speedstep stopped working.

modprobe -v acpi_cpufreq

gives me:

FATAL: Error inserting acpi_cpufreq
(/lib/modules/2.6.30.10-105.fc11.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko):
No such device

By googling a bit I found the thread "[Help] I can't get Intel
Speedstep working" on this list, started in march by Robert Szalai, who
uses a Core 2 duo E7200, which seems to be essentially the same cpu as
the 5300 but with faster bus speed etc.

Since I still had the E2140 (Speedstep actually works with that CPU), I
put it back in so I could do an acpidump with that cpu and compare the
outputs. It seems to me that an SSDT is there when the E2140 is
installed, and when I substitute the 5300 it goes away. Also, a few
bytes in the RSDT differ. The SSDT definitely looks like it contains
speedstep related stuff even though I know nothing about iasl.

Since speedstep with 45ns processors apparently works in windows, would
it be wrong to assume that windows (or whatever drivers Shuttle provide
for windows) keeps a bunch of extra SSDT:s around and kludges them in
if a 45ns CPU is present?

Both acpidumps are attached and if someone creates some kind of patch
I'll of course try it.

Thanks a lot
Rasmus Wiman


[-- Attachment #2: k48-acpi.tar.bz2 --]
[-- Type: application/x-bzip, Size: 26750 bytes --]

Re: Shuttle K48 and speedstep.

[Len Brown]

thanks,
Len Brown, Intel Open Source Technology Center

On Mon, 4 Jan 2010, Rasmus Wiman wrote:

> Hi everybody,
> 
> a few months ago I bought myself a Shuttle K48 to use with Vortexbox as
> a media PC. I put in an old Intel Pentium dual-core E2140 that I had
> lying around. However, even after getting a better fan I still found it
> a bit on the noisy side, so I decided to try a 45ns cpu and got a dual
> core E5300. Better, but now speedstep stopped working.
> 
> modprobe -v acpi_cpufreq
> 
> gives me:
> 
> FATAL: Error inserting acpi_cpufreq
> (/lib/modules/2.6.30.10-105.fc11.i686.PAE/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko):
> No such device
> 
> By googling a bit I found the thread "[Help] I can't get Intel
> Speedstep working" on this list, started in march by Robert Szalai, who
> uses a Core 2 duo E7200, which seems to be essentially the same cpu as
> the 5300 but with faster bus speed etc.
> 
> Since I still had the E2140 (Speedstep actually works with that CPU), I
> put it back in so I could do an acpidump with that cpu and compare the
> outputs. It seems to me that an SSDT is there when the E2140 is
> installed, and when I substitute the 5300 it goes away. Also, a few
> bytes in the RSDT differ. The SSDT definitely looks like it contains
> speedstep related stuff even though I know nothing about iasl.
> 
> Since speedstep with 45ns processors apparently works in windows, would
> it be wrong to assume that windows (or whatever drivers Shuttle provide
> for windows) keeps a bunch of extra SSDT:s around and kludges them in
> if a 45ns CPU is present?
> 
> Both acpidumps are attached and if someone creates some kind of patch
> I'll of course try it.

Your observation is correct.
When the e2140 is installed, the RSDT has an SSDT in it
that is absent when the 5300 is present.  The tables
are otherwise identical.  The SSDT contains the _OSC,
_PDC; and based on what happens at run-time, they load
a dynamic SSDT which presumably includes the cpufreq
related methods.  You will likely find that table
under /sys/firmware/acpi/tables/dynamic/

(we should update acpidump to look there too).

So it looks like the BIOS doesn't recognize one of the CPUs,
so i recommend that you look for an update.

Yes, I'm sure that Windows can handle speedstep on
45nm processors, and I'm sure that Linux can to --
but not using the BIOS on this box.  Did you run
windows on this BIOS and speedstep worked?
That would be puzzling.

thanks,
Len Brown, Intel Open Source Technology Center

Re: Shuttle K48 and speedstep.

[Rasmus Wiman]

Len Brown <lenb@kernel.org> wrote:

> > Since speedstep with 45ns processors apparently works in windows,
> > would it be wrong to assume that windows (or whatever drivers
> > Shuttle provide for windows) keeps a bunch of extra SSDT:s around
> > and kludges them in if a 45ns CPU is present?
> > 
> > Both acpidumps are attached and if someone creates some kind of
> > patch I'll of course try it.
> 
> Your observation is correct.
> When the e2140 is installed, the RSDT has an SSDT in it
> that is absent when the 5300 is present.  The tables
> are otherwise identical.  The SSDT contains the _OSC,
> _PDC; and based on what happens at run-time, they load
> a dynamic SSDT which presumably includes the cpufreq
> related methods.  You will likely find that table
> under /sys/firmware/acpi/tables/dynamic/
> 
> (we should update acpidump to look there too).
> 
> So it looks like the BIOS doesn't recognize one of the CPUs,
> so i recommend that you look for an update.
> 
> Yes, I'm sure that Windows can handle speedstep on
> 45nm processors, and I'm sure that Linux can to --
> but not using the BIOS on this box.  Did you run
> windows on this BIOS and speedstep worked?
> That would be puzzling.

I didn't run windows on the box, Robert Szalai, who created the
original thread, claimed to have done it. But I just located a spare
hard drive, connected it to the K48 and installed Windows 7 beta on it.
And yes, according to CPU-Z speedstep is actually working using this
bios, with the 5300, on this box.

What's the next step from here? Could CPU-Z be lying? If I would
extract the ACPI tables from within windows, would they look the same
as they do when I do an acpidump from Linux? Is there a good tool for
extracting ACPI tables from within windows?

thanks,
Rasmus W