On 22 Feb 2007, at 20:31, Janosch Machowinski wrote:
Actually is could be, that nothing is broken. If the bios does not
export more than one C-State, than everything is (from the view of
linux) ok. If you want to find out, what C-States are exported by
the bios, decompile your DSDT (can be found under /proc/acpi/dsdt)
with the IASL compiler (http://www.intel.com/technology/iapc/acpi/
license2.htm), and search in the decompiled version for _CST. More
information about the _CST object can be found in the ACPI-
Specification (www.acpi.info)
That was just the problem. I upgraded the BIOS and now it provides C1
and C2. And the 2.6.18 kernel is using them.
egimenez@watt:~$ dmesg | grep "power states"
ACPI: CPU0 (power states: C1[C1] C2[C2])
But still there are a couple of strange quirks.
First the DSDT does not provide the _CST object, so I suppose the
kernel is using the P_LVL method. Another BIOS problem... :S
The second one intrigues me more. The 2.6.19, 2.6.20 and 2.6.20.1
kernels does not use nor show the C1 and C2 states. I've been using
the same config file with oldconfig and I've removed problematic
drivers, such as USB.
I would like to solve this behaviour, or at least to find why is
happening. I will start reviewing the dmesg output for each kernel,
to see what changes. Any advice on what and where look for will be
really welcomed :)
--
edu
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
