_CST implementation

_CST implementation

[Janosch Machowinski]

Hey, 
im new to ACPI, so please be patient with my stupid questions ;-)
I spend a little time in debugging my kernel ACPI and reading the 3.0
specs... Now I am wondering about some pieces of the implementation. 
First of all in processor_idle.c in the funktion
acpi_processor_get_power_info_cst there is a test if the power.count is
less than 2. Why do you test on 2 and not on 1 ? As far 
as I can see 1 would be an valid value. 

The next question is about these lines : 
for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
	memset(pr->power.states, 0, sizeof(struct acpi_processor_cx));
what's the sense in doing this up to 8 times ? 
shouldn't it be
for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
       memset(pr->power.states[i], 0, sizeof(struct acpi_processor_cx));
?

The next question is about the ACPI_PROCESSOR_MAX_POWER constant.
The ACPI specification says, that the C states can be expanded "to an
arbitary number of power states" so why do you limit them ? 

And another one about these lines :
cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
			0 : reg->address;
Why is the adress set to 0 in case it is a fixed hardware adress ? 
And why can only C1 have an fixed hardware adress ?

Okay the last thing I am curious about is how should _CST work, 
at the moment the code deletes all known power states (or tries it)
(hm by the way, this could be the reason why the IBM t40 crashes)
and writes all power states given by the _CST object to the
acpi_processor structure. Is this the way it is mentioned to be ? 
I couldn't figure out (of the ACPI Spec), if there could also be a way
of incremental generation of the C states. 

Oh I almost forgot another question : 
About the validation of the C states. At the moment it is tested if the
latency of C2 if under 100 and if C3 latency is under 1000 but the
ACPI-Spec says that "There is no latency restrictions" so why do you do
this ? (My notebook hat a C3 latency of 1001)

Greets
	Janosch Machowinski

P.S.: Sorry about my bad english



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Bruno Ducrot]

On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> Hey, 
> im new to ACPI, so please be patient with my stupid questions ;-)
> I spend a little time in debugging my kernel ACPI and reading the 3.0
> specs... Now I am wondering about some pieces of the implementation. 
> First of all in processor_idle.c in the funktion
> acpi_processor_get_power_info_cst there is a test if the power.count is
> less than 2. Why do you test on 2 and not on 1 ? As far 
> as I can see 1 would be an valid value. 

No.  It cant be a valid value.  Consider this case:

Name (_CST, Package{} {
		1,
		Package{} {ResourceTemplate{} {Register(SystemIO, 8, 0, 0xXXXX), 2, 40, 750}
})


There are *2* elements in the package, an integer (whose value is 1) and
a package defining a C2 state.

> The next question is about these lines : 
> for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
> 	memset(pr->power.states, 0, sizeof(struct acpi_processor_cx));
> what's the sense in doing this up to 8 times ? 
> shouldn't it be
> for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
>        memset(pr->power.states[i], 0, sizeof(struct acpi_processor_cx));
> ?

indeed

> 
> The next question is about the ACPI_PROCESSOR_MAX_POWER constant.
> The ACPI specification says, that the C states can be expanded "to an
> arbitary number of power states" so why do you limit them ? 
> 
> And another one about these lines :
> cx.address = (reg->space_id == ACPI_ADR_SPACE_FIXED_HARDWARE) ?
> 			0 : reg->address;
> Why is the adress set to 0 in case it is a fixed hardware adress ? 

Because if it's different to '0', then actually we should even bail out.
See ACPI spec (I don't remember exactly which part, but well).

> And why can only C1 have an fixed hardware adress ?

An addr space of type Fixed Hardware means (more or less) that its very
dependant of the device considered (no IO, no memory mapped, etc).
In that case, and for an intel ia32, this correspond to 'hlt'.
For other processors, this maybe totally different.

> Okay the last thing I am curious about is how should _CST work, 
> at the moment the code deletes all known power states (or tries it)
> (hm by the way, this could be the reason why the IBM t40 crashes)
> and writes all power states given by the _CST object to the
> acpi_processor structure. Is this the way it is mentioned to be ? 
> I couldn't figure out (of the ACPI Spec), if there could also be a way
> of incremental generation of the C states. 

Me too.  Therefore all C states are regenerated.

> Oh I almost forgot another question : 
> About the validation of the C states. At the moment it is tested if the
> latency of C2 if under 100 and if C3 latency is under 1000 but the
> ACPI-Spec says that "There is no latency restrictions" so why do you do
> this ? (My notebook hat a C3 latency of 1001)

Normally you are right, but unfortunately there are still some strange
misread of the specification by bios writters in that regard.  Therefore
if for C3 the latency is 1001 even if given by _CST, we should disable
it.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Janosch Machowinski]

On Mon, 2005-04-18 at 14:07 +0200, Bruno Ducrot wrote:
> On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> > Hey, 
> > im new to ACPI, so please be patient with my stupid questions ;-)
> > I spend a little time in debugging my kernel ACPI and reading the 3.0
> > specs... Now I am wondering about some pieces of the implementation. 
> > First of all in processor_idle.c in the funktion
> > acpi_processor_get_power_info_cst there is a test if the power.count is
> > less than 2. Why do you test on 2 and not on 1 ? As far 
> > as I can see 1 would be an valid value. 
> 
> No.  It cant be a valid value.  Consider this case:
> 
> Name (_CST, Package{} {
> 		1,
> 		Package{} {ResourceTemplate{} {Register(SystemIO, 8, 0, 0xXXXX), 2, 40, 750}
> })
> 
> 
> There are *2* elements in the package, an integer (whose value is 1) and
> a package defining a C2 state.

I must disagree, power.count is not a variable to test, how many
elements are in the _CST object (that would be count), pr->power.count
is a counter for the number ob C-States that were extracted from the
_CST Object, therefor one C-State is a C-State and should be valid. 
  Janosch



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Bruno Ducrot]

On Mon, Apr 18, 2005 at 02:23:50PM +0200, Janosch Machowinski wrote:
> On Mon, 2005-04-18 at 14:07 +0200, Bruno Ducrot wrote:
> > On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> > > Hey, 
> > > im new to ACPI, so please be patient with my stupid questions ;-)
> > > I spend a little time in debugging my kernel ACPI and reading the 3.0
> > > specs... Now I am wondering about some pieces of the implementation. 
> > > First of all in processor_idle.c in the funktion
> > > acpi_processor_get_power_info_cst there is a test if the power.count is
> > > less than 2. Why do you test on 2 and not on 1 ? As far 
> > > as I can see 1 would be an valid value. 
> > 
> > No.  It cant be a valid value.  Consider this case:
> > 
> > Name (_CST, Package{} {
> > 		1,
> > 		Package{} {ResourceTemplate{} {Register(SystemIO, 8, 0, 0xXXXX), 2, 40, 750}
> > })
> > 
> > 
> > There are *2* elements in the package, an integer (whose value is 1) and
> > a package defining a C2 state.
> 
> I must disagree, power.count is not a variable to test, how many
> elements are in the _CST object (that would be count), pr->power.count
> is a counter for the number ob C-States that were extracted from the
> _CST Object, therefor one C-State is a C-State and should be valid. 
>   Janosch

I think I misread what you wrote.  I was thinking you were refering to
cst->package.count

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Thomas Renninger]

Bruno Ducrot wrote:
> On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
...
> 
>>Oh I almost forgot another question : 
>>About the validation of the C states. At the moment it is tested if the
>>latency of C2 if under 100 and if C3 latency is under 1000 but the
>>ACPI-Spec says that "There is no latency restrictions" so why do you do
>>this ? (My notebook hat a C3 latency of 1001)
> 
> Normally you are right, but unfortunately there are still some strange
> misread of the specification by bios writters in that regard.  Therefore
> if for C3 the latency is 1001 even if given by _CST, we should disable
> it.
> 

My spec says (Revision 3.0, September 2, 2004):
The worst-case hardware latency for this state is declared in the FADT
(p. 257).

And there they say (p. 98):
The worst-case hardware latency, in microseconds, to enter and
exit a C2 state. A value > 100 indicates the system does not
support a C2 state.
The worst-case hardware latency, in microseconds, to enter and
exit a C3 state. A value > 1000 indicates the system does not
support a C3 state.

     Thomas


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Janosch Machowinski]

On Mon, 2005-04-18 at 19:25 +0200, Thomas Renninger wrote:
> Bruno Ducrot wrote:
> > On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> ...
> > 
> >>Oh I almost forgot another question : 
> >>About the validation of the C states. At the moment it is tested if the
> >>latency of C2 if under 100 and if C3 latency is under 1000 but the
> >>ACPI-Spec says that "There is no latency restrictions" so why do you do
> >>this ? (My notebook hat a C3 latency of 1001)
> > 
> > Normally you are right, but unfortunately there are still some strange
> > misread of the specification by bios writters in that regard.  Therefore
> > if for C3 the latency is 1001 even if given by _CST, we should disable
> > it.
> > 
> 
> My spec says (Revision 3.0, September 2, 2004):
> The worst-case hardware latency for this state is declared in the FADT
> (p. 257).
> 
> And there they say (p. 98):
> The worst-case hardware latency, in microseconds, to enter and
> exit a C2 state. A value > 100 indicates the system does not
> support a C2 state.
> The worst-case hardware latency, in microseconds, to enter and
> exit a C3 state. A value > 1000 indicates the system does not
> support a C3 state.
> 
>      Thomas
Hm this is somehow funny. So we could say, that latency values in the
FADT are restricted, and latency values from _CST value are not
restricted (p. 261).  

   Janosch  




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: _CST implementation

[Bruno Ducrot]

On Mon, Apr 18, 2005 at 07:25:54PM +0200, Thomas Renninger wrote:
> Bruno Ducrot wrote:
> > On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> ...
> > 
> >>Oh I almost forgot another question : 
> >>About the validation of the C states. At the moment it is tested if the
> >>latency of C2 if under 100 and if C3 latency is under 1000 but the
> >>ACPI-Spec says that "There is no latency restrictions" so why do you do
> >>this ? (My notebook hat a C3 latency of 1001)
> > 
> > Normally you are right, but unfortunately there are still some strange
> > misread of the specification by bios writters in that regard.  Therefore
> > if for C3 the latency is 1001 even if given by _CST, we should disable
> > it.
> > 
> 
> My spec says (Revision 3.0, September 2, 2004):
> The worst-case hardware latency for this state is declared in the FADT
> (p. 257).
> 
> And there they say (p. 98):
> The worst-case hardware latency, in microseconds, to enter and
> exit a C2 state. A value > 100 indicates the system does not
> support a C2 state.
> The worst-case hardware latency, in microseconds, to enter and
> exit a C3 state. A value > 1000 indicates the system does not
> support a C3 state.
> 

For P_LVL2_LAT and P_LVL3_LAT defined in the FADT only.  There are no
such restriction if _CST exist (see 8.1.5 and 8.4.2).
If power states are defined via _CST, then all of them are valid.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

Re: _CST implementation

[Thomas Renninger]

[-- Attachment #1: Type: text/plain, Size: 1514 bytes --]

Bruno Ducrot wrote:
> On Mon, Apr 18, 2005 at 07:25:54PM +0200, Thomas Renninger wrote:
>>Bruno Ducrot wrote:
>>>On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
>>...
>>>>Oh I almost forgot another question : 
>>>>About the validation of the C states. At the moment it is tested if the
>>>>latency of C2 if under 100 and if C3 latency is under 1000 but the
>>>>ACPI-Spec says that "There is no latency restrictions" so why do you do
>>>>this ? (My notebook hat a C3 latency of 1001)
>>>Normally you are right, but unfortunately there are still some strange
>>>misread of the specification by bios writters in that regard.  Therefore
>>>if for C3 the latency is 1001 even if given by _CST, we should disable
>>>it.
>>>
>>My spec says (Revision 3.0, September 2, 2004):
>>The worst-case hardware latency for this state is declared in the FADT
>>(p. 257).
>>
>>And there they say (p. 98):
>>The worst-case hardware latency, in microseconds, to enter and
>>exit a C2 state. A value > 100 indicates the system does not
>>support a C2 state.
>>The worst-case hardware latency, in microseconds, to enter and
>>exit a C3 state. A value > 1000 indicates the system does not
>>support a C3 state.
>>
> 
> For P_LVL2_LAT and P_LVL3_LAT defined in the FADT only.  There are no
> such restriction if _CST exist (see 8.1.5 and 8.4.2).
> If power states are defined via _CST, then all of them are valid.
> 

Thanks, only knew of the fadt restrictions.
This should fix it?
Only compile tested.

       Thomas

[-- Attachment #2: CST_long_latencies --]
[-- Type: text/plain, Size: 1379 bytes --]

Patch allows longer latencies for _CST provided c-states.
(cmp. with ACPI spec (see 8.1.5 and 8.4.2)).

--- linux-2.6.11.orig/drivers/acpi/processor_idle.c	2005-03-02 08:38:25.000000000 +0100
+++ linux-2.6.11/drivers/acpi/processor_idle.c	2005-04-19 13:47:17.000000000 +0200
@@ -646,7 +646,8 @@
 }
 
 
-static void acpi_processor_power_verify_c2(struct acpi_processor_cx *cx)
+static void acpi_processor_power_verify_c2(struct acpi_processor *pr,
+					   struct acpi_processor_cx *cx)
 {
 	ACPI_FUNCTION_TRACE("acpi_processor_get_power_verify_c2");
 
@@ -657,7 +658,7 @@
 	 * C2 latency must be less than or equal to 100
 	 * microseconds.
 	 */
-	else if (cx->latency > ACPI_PROCESSOR_MAX_C2_LATENCY) {
+	else if (!pr->flags.has_cst && cx->latency > ACPI_PROCESSOR_MAX_C2_LATENCY) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "latency too large [%d]\n",
 				  cx->latency));
@@ -695,7 +696,7 @@
 	 * C3 latency must be less than or equal to 1000
 	 * microseconds.
 	 */
-	else if (cx->latency > ACPI_PROCESSOR_MAX_C3_LATENCY) {
+	else if (!pr->flags.has_cst && cx->latency > ACPI_PROCESSOR_MAX_C3_LATENCY) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "latency too large [%d]\n",
 				  cx->latency));
@@ -757,7 +758,7 @@
 			break;
 
 		case ACPI_STATE_C2:
-			acpi_processor_power_verify_c2(cx);
+			acpi_processor_power_verify_c2(pr, cx);
 			break;
 
 		case ACPI_STATE_C3:

Re: _CST implementation

[Bruno Ducrot]

On Tue, Apr 19, 2005 at 01:58:09PM +0200, Thomas Renninger wrote:
> Bruno Ducrot wrote:
> > On Mon, Apr 18, 2005 at 07:25:54PM +0200, Thomas Renninger wrote:
> >>Bruno Ducrot wrote:
> >>>On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> >>...
> >>>>Oh I almost forgot another question : 
> >>>>About the validation of the C states. At the moment it is tested if the
> >>>>latency of C2 if under 100 and if C3 latency is under 1000 but the
> >>>>ACPI-Spec says that "There is no latency restrictions" so why do you do
> >>>>this ? (My notebook hat a C3 latency of 1001)
> >>>Normally you are right, but unfortunately there are still some strange
> >>>misread of the specification by bios writters in that regard.  Therefore
> >>>if for C3 the latency is 1001 even if given by _CST, we should disable
> >>>it.
> >>>
> >>My spec says (Revision 3.0, September 2, 2004):
> >>The worst-case hardware latency for this state is declared in the FADT
> >>(p. 257).
> >>
> >>And there they say (p. 98):
> >>The worst-case hardware latency, in microseconds, to enter and
> >>exit a C2 state. A value > 100 indicates the system does not
> >>support a C2 state.
> >>The worst-case hardware latency, in microseconds, to enter and
> >>exit a C3 state. A value > 1000 indicates the system does not
> >>support a C3 state.
> >>
> > 
> > For P_LVL2_LAT and P_LVL3_LAT defined in the FADT only.  There are no
> > such restriction if _CST exist (see 8.1.5 and 8.4.2).
> > If power states are defined via _CST, then all of them are valid.
> > 
> 
> Thanks, only knew of the fadt restrictions.
> This should fix it?
> Only compile tested.

There is this problem:
> >>>Normally you are right, but unfortunately there are still some strange
> >>>misread of the specification by bios writters in that regard.  Therefore
> >>>if for C3 the latency is 1001 even if given by _CST, we should disable
> >>>it.

IOW, from spec we should not invalidate, but from "common practice" by
bios writters, we should invalidate.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

Re: _CST implementation

[Stefan Seyfried]

On Tue, Apr 19, 2005 at 03:45:18PM +0200, Bruno Ducrot wrote:

> IOW, from spec we should not invalidate, but from "common practice" by
> bios writters, we should invalidate.

What about a "spec_compliant_but_beware_of_stupid_bios_writers" module
parameter? ;-)
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

Re: Re: _CST implementation

[Rich Townsend]

Stefan Seyfried wrote:
> On Tue, Apr 19, 2005 at 03:45:18PM +0200, Bruno Ducrot wrote:
> 
> 
>>IOW, from spec we should not invalidate, but from "common practice" by
>>bios writters, we should invalidate.
> 
> 
> What about a "spec_compliant_but_beware_of_stupid_bios_writers" module
> parameter? ;-)

I fear that would be set to nonzero on every system...

:)



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

Re: Re: _CST implementation

[Bruno Ducrot]

On Tue, Apr 19, 2005 at 04:11:45PM -0400, Rich Townsend wrote:
> Stefan Seyfried wrote:
> > On Tue, Apr 19, 2005 at 03:45:18PM +0200, Bruno Ducrot wrote:
> > 
> > 
> >>IOW, from spec we should not invalidate, but from "common practice" by
> >>bios writters, we should invalidate.
> > 
> > 
> > What about a "spec_compliant_but_beware_of_stupid_bios_writers" module
> > parameter? ;-)
> 
> I fear that would be set to nonzero on every system...
> 

That's the case already.  This is the boot parameter
acpi=strict


-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

Re: Re: _CST implementation

[Thomas Renninger]

Bruno Ducrot wrote:
> On Tue, Apr 19, 2005 at 04:11:45PM -0400, Rich Townsend wrote:
>>Stefan Seyfried wrote:
>>>On Tue, Apr 19, 2005 at 03:45:18PM +0200, Bruno Ducrot wrote:
>>>
>>>
>>>>IOW, from spec we should not invalidate, but from "common practice" by
>>>>bios writters, we should invalidate.
>>>
>>>What about a "spec_compliant_but_beware_of_stupid_bios_writers" module
>>>parameter? ;-)
>>I fear that would be set to nonzero on every system...
>>
> 
> That's the case already.  This is the boot parameter
> acpi=strict

I do not think it is a good idea to make this depend on acpi=strict.

Normally !acpi_strict enables features for some broken BIOS.
In this case !acpi_strict disables them.

There still is max_cstates if something goes terribly wrong.
I never saw such a machine, are there many of them out there?

Janosch: Did you get the 1001 latency state to work?


    Thomas


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: _CST implementation

[Janosch Machowinski]

Thomas Renninger schrieb:
> Bruno Ducrot wrote:
> 
>>On Tue, Apr 19, 2005 at 04:11:45PM -0400, Rich Townsend wrote:
>>
>>>Stefan Seyfried wrote:
>>>
>>>>On Tue, Apr 19, 2005 at 03:45:18PM +0200, Bruno Ducrot wrote:
>>>>
>>>>
>>>>
>>>>>IOW, from spec we should not invalidate, but from "common practice" by
>>>>>bios writters, we should invalidate.
>>>>
>>>>What about a "spec_compliant_but_beware_of_stupid_bios_writers" module
>>>>parameter? ;-)
>>>
>>>I fear that would be set to nonzero on every system...
>>>
>>
>>That's the case already.  This is the boot parameter
>>acpi=strict
> 
> 
> I do not think it is a good idea to make this depend on acpi=strict.
> 
> Normally !acpi_strict enables features for some broken BIOS.
> In this case !acpi_strict disables them.
> 
> There still is max_cstates if something goes terribly wrong.
> I never saw such a machine, are there many of them out there?
> 
> Janosch: Did you get the 1001 latency state to work?
> 
The 1001 latency C3 state was in my case from the P_BLK. My Notebook 
worked fine with it, but actually the power consumption was as high as 
in the C2 state.

I would suggest a parameter for disabling _CST, because it is new (and 
buggy) code.

   Janosch


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click