Re: hi, i am having issues with the intel q8400s and p8600 cpu. no freq scaling.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wednesday 09 December 2009 11:11:14 pm Rüdiger Kramolisch wrote:
> hi,
> Am Mittwoch 09 Dezember 2009 20:37:57 schrieben Sie:
> > Hi,
> > On Wednesday 09 December 2009 06:20:06 pm Rüdiger Kramolisch wrote:
> > > hi,
> > >
> > > i am having issues with the intel q8400s and p8600 cpu. both dont do
> > > frequency scaling.
> >
> > The newer CPUs might be unknown to the BIOS?
> > Did you upgrade the CPUs?
>
> yes to both. q8400s is upgrade, the p8400 is for a new computer... (both
> self built)
>
> > Best try a BIOS update. If it still does not work check whether they
> > should be fully supported.
>
> q8400s:
> i did the bios update before the cpu update :)
>
> according to this page:
> http://processormatch.intel.com/CompDB/SearchResult.aspx?Boardname=DP35DP
> the cpu is compatible with my board.
But it looks like the vendor did not add freq data for all CPUs.

> there is no newer bios than the one i have.
> http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=De
>sktop+Boards&ProductLine=Intel%C2%AE+3+Series+Chipset+Boards&ProductProduct=
>Intel%C2%AE+Desktop+Board+DP35DP
>
> http://imagebin.ca/view/oheuESY.html
>
> who would have thought it is working under windows :/ but it embezzles the
> SSE4 instruction set.
> http://imagebin.ca/view/ylUS9vC7.html
You mean on that picture one can see the processor's max at 2,666 MHz and the
current speed is at 2,000 MHz?
Strange I thought Windows is also using ACPI cpufreq info.
Possibly there is another power saving mechanism kicking in (eventl. HW driven C1E)
which also happens, but is not shown on Linux?
Make sure you also have disassembled and grepped over the SSDTs.
Hmm and there could be dynamically loaded SSDTs which do not get dumped with
acpidump.
It is possible to find them and the starting address by:
grep -i load "*.dsl"
but you have to look up the ACPI code at that place to identify from which address
the SSDT table gets loaded at runtime and the length of it.
Then acpidump -addr xy -len zz (or similar) dumps it.
Adding something to acpi-cpufreq that checks whether the CPU is not older than say
3 years, has EST (speedstep) flag set and the BIOS does not expose ACPI cpufreq info,
then complain about the BIOS missing cpufreq info...

What is the output in syslog/dmesg if you try to load acpi-cpufreq?

   Thomas
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Devel]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Forum]     [Linux SCSI]

  Powered by Linux