From: Erik Slagter <erik@slagter.name>
To: ykzhao <yakui.zhao@intel.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: No c2-c7 states on core i7
Date: Mon, 23 Nov 2009 09:52:50 +0100 [thread overview]
Message-ID: <4B0A4D62.2040001@slagter.name> (raw)
In-Reply-To: <1258945512.3773.33.camel@localhost.localdomain>
On 23-11-09 04:05, ykzhao wrote:
> On Fri, 2009-11-20 at 22:28 +0800, Erik Slagter wrote:
>> Hi there,
>>
>> I already put on my flame retardant underwear, I know this is a FAQ, but
>> I really need a bit of a jumpstart, google won't tell me where to start,
>> so please be gentle ;-)
>>
>> I bought a Gigabyte EX58-UD3R motherboard recently and put a core i7 920
>> on it. This seems to be a fairly common combination.
>>
>> In short: I know the core i7 does implement several C-states, from
>> memory c1, c1e, c3, c6 and c7. Linux (vanilla, 2.6.31.6) does not
>> recognise any of them.
>>
>> The kernel configuration is very similar to the one I am running on my
>> laptop with a recent mobile core2duo processor, and this one reports
>> C1,C2,C3 (although it should also report yet another C state, but I
>> guess that one is disabled by the bios or something alike).
>>
>> Is this normal (WIP?)?
>>
>> If not, where should I start debugging? I know there is "something" with
>> decoding the DSDT table, but what should I look for?
>>
>> I seem to remember that with an earlier linux version (before 2.6.30.5)
>> it actually did work, but I am not completely sure.
>>
>> Thanks for your help in advance!
>>
>> Additional info that might be useful:
>>
>> - all options related to power saving and C-states are ENABLED in the BIOS
>> - all options related to power management and idling are ENABLED in the
>> kernel, which runs in 64 bits mode
>> - frequency switching runs fine using acpi-cpufreq and ondemand governor
>>
>> If I compare the dmesg from both computers after booting, the laptop
>> says "ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3])" at some point,
>> this message is not output at all by the server.
>>
>> Output from proc/acpi/processor/CPU0/info
>> processor id: 0
>> acpi id: 0
>> bus mastering control: yes
>> power management: no
>> throttling control: yes
>> limit interface: yes
>>
>> Output from proc/acpi/processor/CPU0/power
>> active state: C0
>> max_cstate: C8
>> maximum allowed latency: 2000000000 usec
>> states:
>> C1: type[C1] promotion[--] demotion[--]
>> latency[000] usage[00000000] duration[00000000000000000000]
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Will you please attach the output of acpidump on the machine with the
> core i7 cpu?
> Please attach the output of every file
> under /sys/firmware/acpi/tables/dynamic/SSDT*?
> cat /sys/firmware/acpi/tables/dynamic/SSDT1> ssdt1
>
> Please also attach the output of /proc/cpuinfo.
Hi,
Thank you for your attention. This specific issue has already been
solved for me, it turns out be yet another bios issue (as I have
experienced before). Enable base clock setting and all C states are gone!
But now I have a few other issues that maybe you can help me with:
- How are intel core i7 C states mapped to linux C states? Both my
laptop (core2duo T9300) and desktop (core i7 920) should have
c1-c3-c6-c7, but on both machines linux only sees c1-c2-c3.
- On said desktop, I see no difference in power consumption with c
states enabled or disabled; if they're enabled (and base clock control
is off...) linux is using c3 almost all of the time, but power
consumption remains the same (about 110 watts for the complete
motherboard, is that normal?).
- From a quick inspection of the acpi tables (I am not quite an expert
on this...) it looks like a number of _CST objects are exported with
default bios settings, while with base clock control enabled, these are
gone. I would to try (yes I know, not recommended, etc.) to copy the
_CST objects from the one boot instance's tables to the other. Now I
think of it, it would probably even suffice to boot one time with
baseclock control disabled, record the acpi tables (SSDT?) and then make
the kernel use that in subsequent boots with the base clock control
enabled (with all other bios settings the same, off course). Is that
difficult to achieve? I seem to remember that's possible one way or another.
Thanks for your help!
P.S. I am going to have a look at the /sys/* files you mentioned anyway,
I didn't even know they were there!
next prev parent reply other threads:[~2009-11-23 8:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-20 14:28 No c2-c7 states on core i7 Erik Slagter
2009-11-21 17:45 ` Erik Slagter
2009-11-22 11:46 ` c1/c1e/c3/c6/c7 on linux Erik Slagter
2009-11-23 3:05 ` No c2-c7 states on core i7 ykzhao
2009-11-23 8:52 ` Erik Slagter [this message]
2009-11-23 16:11 ` Len Brown
2009-11-23 19:23 ` Erik Slagter
2009-11-23 19:26 ` Erik Slagter
2009-11-24 13:34 ` Jindrich Makovicka
2009-11-24 13:55 ` Erik Slagter
2009-11-25 6:59 ` Len Brown
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=4B0A4D62.2040001@slagter.name \
--to=erik@slagter.name \
--cc=linux-acpi@vger.kernel.org \
--cc=yakui.zhao@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox