From: Thomas Renninger <trenn@suse.de>
To: Greg Oliver <oliver.greg2@gmail.com>
Cc: linux-acpi@vger.kernel.org
Subject: Re: Core i7 & C-States
Date: Fri, 19 Nov 2010 01:59:31 +0100 [thread overview]
Message-ID: <201011190159.32152.trenn@suse.de> (raw)
In-Reply-To: <AANLkTik+zt0FC7chXJojaqtAMC5DsfLHKcU1FVAJEXAn@mail.gmail.com>
On Wednesday 17 November 2010 09:34:43 pm Greg Oliver wrote:
> Hi,
>
> This is my first motherboard with ACPI issues, so I am in uncharted
> water. It is an intel board, so no overclocking, etc. Reading through
> as much as I can this morning, I have hit the wall. I have
> disassembled all of my [DS]SDTs, and will attach them with a dmesg as
> this seems to be the normal request from the archives.
>
> About the issue though -
>
> If I enable either/or C-STATES/C2-STATES,
How do you enable them? I expect you disable them (disabling these
does vary depending whether intel_idle or acpi_idle is used, see below)?
> the system will freeze on
> boot. Disabling them both the system runs fine, but I would obviously
> like the power savings if possible. Now I know this BIOS has some
> issues as some PCI devices (when disabled in the BIOS) still get
> partially enumerated and assigned IRQs on the bus as well, but that
> does not concern me as much as the power. The latest update to the
> BIOS from intel is installed.
Interesting.
Which kernel are you running?
With latest kernel intel_idle should be used for C-states on such
a new CPU and it will totally
ignore ACPI C-state information. If it works, it's due to ACPI tables.
You can check here:
cat /sys/devices/system/cpu/cpuidle/current_driver
That should show acpi_idle if processor.ko driver is used and ACPI
tables are used or intel_idle.
> This is the only ACPI error I get from dmesg currently though:
>
> ACPI Warning: Incorrect checksum in table [SSDT] - 3F, should be 91
> (20090903/tbutils-314)
Probably irrelvant to C-states.
>
> I have also booted with "acpi.debug_layer=0xFFFFFFFF
> acpi.debug_level=0x80000000" appended to my kernel cmdline and I am
> unsure why, but even though the system showed all debugs enabled in
> /sys, I did not receive any extra debug messages in dmesg!?!?
For C-states this debug facility does not help much.
If intel_idle also freezes the machine, you should open a bug on
bugzilla.kernel.org, please add me and Len Brown to CC then.
Thomas
next prev parent reply other threads:[~2010-11-19 0:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 20:34 Core i7 & C-States Greg Oliver
2010-11-19 0:59 ` Thomas Renninger [this message]
[not found] ` <AANLkTi=QWXnPwEHBUmaL+PE==pxdTq=gRX_LjuF0L8Mp@mail.gmail.com>
2010-11-21 16:47 ` Thomas Renninger
2010-11-22 1:30 ` Koornstra, Reinoud
2010-11-22 9:22 ` Thomas Renninger
2010-11-22 10:32 ` Koornstra, Reinoud
2010-11-22 22:36 ` Moore, Robert
2010-11-22 22:48 ` Thomas Renninger
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=201011190159.32152.trenn@suse.de \
--to=trenn@suse.de \
--cc=linux-acpi@vger.kernel.org \
--cc=oliver.greg2@gmail.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