C-States Usage/Accounting

C-States Usage/Accounting

[Eduard Giménez Cerdà]

Hello,

I've two machines with the following configuration:
	Processor:	Intel Core Solo T1300 / Intel Celeron M 420
	Mainboard:	Asus N4L-VM DH with Intel 945GM Chipset with an AMI BIOS
	(I suppose the drives and the memory are not important)

With the vanilla kernels 2.6.18 and 2.6.19 the /proc/acpi/processor/ 
CPU1/info file shows that there is no bus mastering nor power  
management, and looking at /proc/acpi/processor/CPU1/power the states  
accounting only shows the C1 state but without any data (0 or -- on  
all the values), although it shows that the maximum C-State is C8.

Now, I'm trying to determine why ACPI does not work. Both processors  
and the mainboard chipset support ACPI, so perhaps it's the BIOS?  
I've been reading the ACPI documentation, the dmesg output, and  
googling but I can't find an answer.

How can I determine which is the faulty part in the system?

Thanks in advance!

--  

edu

Re: C-States Usage/Accounting

[Janosch Machowinski]

Eduard Giménez Cerdà schrieb:
> Hello,
> 
> I've two machines with the following configuration:
>     Processor:    Intel Core Solo T1300 / Intel Celeron M 420
>     Mainboard:    Asus N4L-VM DH with Intel 945GM Chipset with an AMI BIOS
>     (I suppose the drives and the memory are not important)
> 
> With the vanilla kernels 2.6.18 and 2.6.19 the 
> /proc/acpi/processor/CPU1/info file shows that there is no bus mastering 
> nor power management, and looking at /proc/acpi/processor/CPU1/power the 
> states accounting only shows the C1 state but without any data (0 or -- 
> on all the values), although it shows that the maximum C-State is C8.
C8 is the maximum C-State supported by Linux.

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)

	Janosch

-
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

C-States usage on 2.6.18 is ok, but fails on 2.6.{19,20,20.1} (was: C-States Usage/Accounting)

[Eduard Giménez Cerdà]

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