C states on AMD SMP

C states on AMD SMP

[Erik Slagter]

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

Hi,

I compiled & installed 2.6.13 (vanilla) on my Tyan Tiger S2466 (AMD768
chipset, 2xathlon MP 2600) yesterday. Indeed, as expected, acpi
"/proc/acpi/processor/*/power" (C states) is now supported on SMP. But,
to my surprise, it only shows one C state (C1), which, I assume, is
full-on. I am not completely sure about the CPU, but I do know that at
least the chipset supports C2 and C3 states (even got it sort of working
with pm_amd76x).

Can someone shine some light on this?

active state:            C1
max_cstate:              C8
bus master activity:     00000000
states:
   *C1:                  type[C1] promotion[--] demotion[--]
latency[000] usage[59379522]

--- 8-< ----

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 8
model name      : AMD Athlon(tm) Processor
stepping        : 1
cpu MHz         : 2133.515
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
bogomips        : 4266.27

Thx.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Pavel Troller]

> Hi,
> 
> I compiled & installed 2.6.13 (vanilla) on my Tyan Tiger S2466 (AMD768
> chipset, 2xathlon MP 2600) yesterday. Indeed, as expected, acpi
> "/proc/acpi/processor/*/power" (C states) is now supported on SMP. But,
> to my surprise, it only shows one C state (C1), which, I assume, is
> full-on. I am not completely sure about the CPU, but I do know that at
> least the chipset supports C2 and C3 states (even got it sort of working
> with pm_amd76x).
> 
> Can someone shine some light on this?
> 
> active state:            C1
> max_cstate:              C8
> bus master activity:     00000000
> states:
>    *C1:                  type[C1] promotion[--] demotion[--] latency[000] usage[59379522]
> 
Hi!
  I have MSI K7D Master with the same chipset and the same problem :-).
  Try to dump Your FADT. Mine is as follows:

# cat /proc/acpi/fadt | acpitbl
Signature:        FACP
Length:           244
Revision:         0x01
Checksum:         0x5f
OEMID:            AMD2P
OEM Table ID:     AWRDACPI
OEM Revision:     0x42302e31
Creator ID:       AWRD
Creator Revision: 0x00000000
FIRMWARE_CTRL:    0x1fff0000
DSDT:             0x1fff30c0
INT_MODEL:        0x01
SCI_INT:          9
SMI_CMD:          0x0000062f
ACPI_ENABLE:      0xa1
ACPI_DISABLE:     0xa0
S4BIOS_REQ:       0x00
PM1a_EVT_BLK:     0x00000600
PM1b_EVT_BLK:     0x00000000
PM1a_CNT_BLK:     0x00000604
PM1b_CNT_BLK:     0x00000000
PM2_CNT_BLK:      0x00000000
PM_TMR_BLK:       0x00000608
GPE0_BLK:         0x00000620
GPE1_BLK:         0x00000000
PM1_EVT_LEN:      4
PM1_CNT_LEN:      2
PM2_CNT_LEN:      0
PM_TM_LEN:        4
GPE0_BLK_LEN:     4
GPE1_BLK_LEN:     0
GPE1_BASE:        0
P_LVL2_LAT:       101
P_LVL3_LAT:       1001
FLUSH_SIZE:       0
FLUSH_STRIDE:     0
DUTY_OFFSET:      1
DUTY_WIDTH:       1
DAY_ALRM:         0x7d
MON_ALRM:         0x7e
CENTURY:          0x7f
Flags:            0x00000000

Do You see ? P_LVL2_LAT is 101 and P_LVL3_LAT is 1001, exactly 1 ms ABOVE the
maximum stated in the ACPI spec as allowed. Somebody at Tyan (or MSI in my
case) decided to disable generic C2/C3 support. Maybe because the chipset 
requires more care to handle the C2/C3 states than described in the ACPI spec.

I'm using pm_amd76x regularly too, and it works perfectly!
                                           Regards, Pavel Troller


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Janosch Machowinski]

Erik Slagter schrieb:
> Hi,
> 
> I compiled & installed 2.6.13 (vanilla) on my Tyan Tiger S2466 (AMD768
> chipset, 2xathlon MP 2600) yesterday. Indeed, as expected, acpi
> "/proc/acpi/processor/*/power" (C states) is now supported on SMP. But,
> to my surprise, it only shows one C state (C1), which, I assume, is
> full-on. I am not completely sure about the CPU, but I do know that at
> least the chipset supports C2 and C3 states (even got it sort of working
> with pm_amd76x).
> 
> Can someone shine some light on this?
> 
> active state:            C1
> max_cstate:              C8
> bus master activity:     00000000
> states:
>    *C1:                  type[C1] promotion[--] demotion[--]
> latency[000] usage[59379522]
> 
> --- 8-< ----
> 
> processor       : 1
> vendor_id       : AuthenticAMD
> cpu family      : 6
> model           : 8
> model name      : AMD Athlon(tm) Processor
> stepping        : 1
> cpu MHz         : 2133.515
> cache size      : 256 KB
> fdiv_bug        : no
> hlt_bug         : no
> f00f_bug        : no
> coma_bug        : no
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow
> bogomips        : 4266.27
> 
> Thx.

Uhm Linux can't detect something, that is not given by your DSDT...
Even if the CPU and the Chipset support C80, als long as your DSDT does 
not define these states, Linux can't detect them. Extract your DSDT, 
decompile it and search it for the _CST and P_BLK structs. Then verify 
if these structs acually contain C-States (There are some latency 
restrictions for the C-States defined in the P_BLK, for more information 
see www.acpi.info). If you done this please report back.
     Janosch


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

[-- Attachment #1.1: Type: text/plain, Size: 889 bytes --]

On Thu, 2005-09-08 at 13:53 +0200, Janosch Machowinski wrote:
> Uhm Linux can't detect something, that is not given by your DSDT...
> Even if the CPU and the Chipset support C80, als long as your DSDT does 
> not define these states, Linux can't detect them. Extract your DSDT, 
> decompile it and search it for the _CST and P_BLK structs. Then verify 
> if these structs acually contain C-States (There are some latency 
> restrictions for the C-States defined in the P_BLK, for more information 
> see www.acpi.info). If you done this please report back.

Sorry, I am a newbie at this.

I did this: cp /proc/acpi/dsdt .; iasl -d dsdt

This yields a file called dsdt.dsl, which does not contain any string
like _CST or P_BLK. What am I doing wrong here?

Attached is the file in question.

Try #2 with gzipped output to keep the size down. Sorry for the inconvenience.

[-- Attachment #1.2: dsdt.dsl.gz --]
[-- Type: application/x-gzip, Size: 5870 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Janosch Machowinski]

Erik Slagter wrote:
> On Thu, 2005-09-08 at 13:53 +0200, Janosch Machowinski wrote:
> 
>>Uhm Linux can't detect something, that is not given by your DSDT...
>>Even if the CPU and the Chipset support C80, als long as your DSDT does 
>>not define these states, Linux can't detect them. Extract your DSDT, 
>>decompile it and search it for the _CST and P_BLK structs. Then verify 
>>if these structs acually contain C-States (There are some latency 
>>restrictions for the C-States defined in the P_BLK, for more information 
>>see www.acpi.info). If you done this please report back.
> 
> 
> Sorry, I am a newbie at this.
> 
> I did this: cp /proc/acpi/dsdt .; iasl -d dsdt
> 
> This yields a file called dsdt.dsl, which does not contain any string
> like _CST or P_BLK. What am I doing wrong here?
Ups my fault ;-)
The P_BLK is actually defined int the FADT...
And you do not have a _CST object, cause it would habe been decalared here :
     Scope (\_PR)
     {
         Processor (CPU0, 0x00, 0x00008010, 0x06) {}
         Processor (CPU1, 0x01, 0x00000000, 0x00) {}
     }


The little 0x06 after CPU0 tells us that there is an P_BLK,
but like pavel told us, I think the OEM of the Mainboard disabled C2 and 
  C3, but you are free to verify it ;-)
    Janosch


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

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

On Fri, 2005-09-09 at 12:08 +0200, Janosch Machowinski wrote:

> The P_BLK is actually defined int the FADT...
> And you do not have a _CST object, cause it would habe been decalared here :
>      Scope (\_PR)
>      {
>          Processor (CPU0, 0x00, 0x00008010, 0x06) {}
>          Processor (CPU1, 0x01, 0x00000000, 0x00) {}
>      }
> 
> 
> The little 0x06 after CPU0 tells us that there is an P_BLK,
> but like pavel told us, I think the OEM of the Mainboard disabled C2 and 
>   C3, but you are free to verify it ;-)

Indeed:

Signature:        FACP
Length:           244
Revision:         0x01
Checksum:         0xf7
OEMID:            AMD
OEM Table ID:     TECATE
OEM Revision:     0x06040000
Creator ID:       PTL
Creator Revision: 0x000f4240
FIRMWARE_CTRL:    0x3fefffc0
DSDT:             0x3fefcf54
INT_MODEL:        0x00
SCI_INT:          9
SMI_CMD:          0x0000802f
ACPI_ENABLE:      0xf0
ACPI_DISABLE:     0xf1
S4BIOS_REQ:       0x00
PM1a_EVT_BLK:     0x00008000
PM1b_EVT_BLK:     0x00000000
PM1a_CNT_BLK:     0x00008004
PM1b_CNT_BLK:     0x00000000
PM2_CNT_BLK:      0x00000000
PM_TMR_BLK:       0x00008008
GPE0_BLK:         0x00008020
GPE1_BLK:         0x00000000
PM1_EVT_LEN:      4
PM1_CNT_LEN:      2
PM2_CNT_LEN:      0
PM_TM_LEN:        4
GPE0_BLK_LEN:     4
GPE1_BLK_LEN:     0
GPE1_BASE:        0
P_LVL2_LAT:       101
P_LVL3_LAT:       1001
FLUSH_SIZE:       0
FLUSH_STRIDE:     0
DUTY_OFFSET:      1
DUTY_WIDTH:       0
DAY_ALRM:         0x0d
MON_ALRM:         0x00
CENTURY:          0x32
Flags:            0x00000005

Is there a way to patch the FADT or to fool linux-acpi into it does
actually work (to at least be able to test the thing)?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Janosch Machowinski]

Erik Slagter wrote:
> On Fri, 2005-09-09 at 12:08 +0200, Janosch Machowinski wrote:
> 
> 
>>The P_BLK is actually defined int the FADT...
>>And you do not have a _CST object, cause it would habe been decalared here :
>>     Scope (\_PR)
>>     {
>>         Processor (CPU0, 0x00, 0x00008010, 0x06) {}
>>         Processor (CPU1, 0x01, 0x00000000, 0x00) {}
>>     }
>>
>>
>>The little 0x06 after CPU0 tells us that there is an P_BLK,
>>but like pavel told us, I think the OEM of the Mainboard disabled C2 and 
>>  C3, but you are free to verify it ;-)
> 
> 
> Indeed:
> 
> Signature:        FACP
> Length:           244
> Revision:         0x01
> Checksum:         0xf7
> OEMID:            AMD
> OEM Table ID:     TECATE
> OEM Revision:     0x06040000
> Creator ID:       PTL
> Creator Revision: 0x000f4240
> FIRMWARE_CTRL:    0x3fefffc0
> DSDT:             0x3fefcf54
> INT_MODEL:        0x00
> SCI_INT:          9
> SMI_CMD:          0x0000802f
> ACPI_ENABLE:      0xf0
> ACPI_DISABLE:     0xf1
> S4BIOS_REQ:       0x00
> PM1a_EVT_BLK:     0x00008000
> PM1b_EVT_BLK:     0x00000000
> PM1a_CNT_BLK:     0x00008004
> PM1b_CNT_BLK:     0x00000000
> PM2_CNT_BLK:      0x00000000
> PM_TMR_BLK:       0x00008008
> GPE0_BLK:         0x00008020
> GPE1_BLK:         0x00000000
> PM1_EVT_LEN:      4
> PM1_CNT_LEN:      2
> PM2_CNT_LEN:      0
> PM_TM_LEN:        4
> GPE0_BLK_LEN:     4
> GPE1_BLK_LEN:     0
> GPE1_BASE:        0
> P_LVL2_LAT:       101
> P_LVL3_LAT:       1001
> FLUSH_SIZE:       0
> FLUSH_STRIDE:     0
> DUTY_OFFSET:      1
> DUTY_WIDTH:       0
> DAY_ALRM:         0x0d
> MON_ALRM:         0x00
> CENTURY:          0x32
> Flags:            0x00000005
> 
> Is there a way to patch the FADT or to fool linux-acpi into it does
> actually work (to at least be able to test the thing)?
Shure, patch the verify functions in processor_idle.c ...
But actually I think this is no good idea...
    Janosch


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

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

On Sat, 2005-09-10 at 10:59 +0200, Janosch Machowinski wrote:

> > Is there a way to patch the FADT or to fool linux-acpi into it does
> > actually work (to at least be able to test the thing)?
> Shure, patch the verify functions in processor_idle.c ...
> But actually I think this is no good idea...

Testing purposes ;-)

BTW amd76x_pm does work, so you never know... I'd really be happy if I
could get something off the 190 Watts the machine now dissipates
constantly!

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Pavel Troller]

> On Sat, 2005-09-10 at 10:59 +0200, Janosch Machowinski wrote:
> 
> > > Is there a way to patch the FADT or to fool linux-acpi into it does
> > > actually work (to at least be able to test the thing)?
> > Shure, patch the verify functions in processor_idle.c ...
> > But actually I think this is no good idea...
> 
> Testing purposes ;-)
> 
> BTW amd76x_pm does work, so you never know... I'd really be happy if I
> could get something off the 190 Watts the machine now dissipates
> constantly!

Hi!
  AFAIK, the Cx state transition mechanism described in the ACPI spec is
designed just very simply: CPU accesses the "sleep register" stated in the
FACP for the particular sleep level, does the dummy operation, and hardware
puts CPU to the desired sleep level. But, what to do, if the chipset is 
designed that it requires more than a single access ? I'm afraid that it will
then require a specialized driver for that purpose. 
  Did You look at the amd76x_pm sources ? I did, just to see what it
does. There is a plenty of registers accessed, bits set/cleared from them,
simply something, which is not present in plain processor_idle.c . Why this
code is there ? Probably because it is necessary to handle sleep states on this
chipset. I'm afraid that using just the "plain method" from ACPI spec
implemented in the kernel is not enough. It is also the reason why this method
is disabled in BIOS.
  I'm also using amd76x_pm and it's really wonderful, the CPUs cool down to 45C
from 75C, I can even stop the fans and the temp doesn't go above 60C if the
CPUs are idling. I've written a small script using lm_sensors and controlling
fans, it's nice - You start a compilation and fans turn on 5 seconds later,
it's finished and they stop almost immediately. Nice accoustic indication :-).
   THe same problem as with this machine I have with my notebook, Clevo D610SU,
with SiS650 chipset. The C2/3 lats are set to 190/1900 in FADT. I patched the
lat limits in include/acpi/processor.h to 200/2000. Now CPU enters C2 but it
doesn't save more power than in C1. C3 is not entered at all because of bus 
mastering issues.
   I would be very glad for some "sis650_pm" driver but I don't have any. 
   Windows can run about two times longer than my Linux on the same hardware
   :-(.
                     With regards, Pavel Troller


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

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

On Sat, 2005-09-10 at 12:01 +0200, Pavel Troller wrote:

> > > > Is there a way to patch the FADT or to fool linux-acpi into it does
> > > > actually work (to at least be able to test the thing)?
> > > Shure, patch the verify functions in processor_idle.c ...
> > > But actually I think this is no good idea...
> > 
> > Testing purposes ;-)
> > 
> > BTW amd76x_pm does work, so you never know... I'd really be happy if I
> > could get something off the 190 Watts the machine now dissipates
> > constantly!

>   AFAIK, the Cx state transition mechanism described in the ACPI spec is
> designed just very simply: CPU accesses the "sleep register" stated in the
> FACP for the particular sleep level, does the dummy operation, and hardware
> puts CPU to the desired sleep level.

Yeah, that's right. The amd 768 chipset does it exactly this way. I have
the documentation here because I fiddled a lot with amd768 and didn't
manage to do it the right thing (which means: full power when needed
(+bus mastering), minimum power when idle).

I do know C2/C3 works, because if you call it from the idle loop, about
20 times in a row, your computer will become dead slow ;-)

> But, what to do, if the chipset is 
> designed that it requires more than a single access ? I'm afraid that it will
> then require a specialized driver for that purpose. 

In that case it's not acpi compliant. IMHO it shouldn't be mentioned in
the acpi tables anyway...

>   Did You look at the amd76x_pm sources?

Yes ;-)

> I did, just to see what it
> does. There is a plenty of registers accessed, bits set/cleared from them,
> simply something, which is not present in plain processor_idle.c.

a) mostly for the amd760 chipset (as opposed to amd768)
b) some registers are already set by default or by bios
c) some registers enable some extra savings

>  I'm also using amd76x_pm and it's really wonderful, the CPUs cool down to 45C
> from 75C, I can even stop the fans and the temp doesn't go above 60C if the
> CPUs are idling.

See above. It doesn't do the right thing, especially not using bus
mastering (like video capturing cards).


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Pavel Troller]

Hi!

> > I did, just to see what it
> > does. There is a plenty of registers accessed, bits set/cleared from them,
> > simply something, which is not present in plain processor_idle.c.
> 
> a) mostly for the amd760 chipset (as opposed to amd768)
But which chipset is in my machine, when for example lspci shows:
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04)
Is it a compbination of 760/768 ? If the important part is in the first line, 
does it mean that it cannot work that simple as a "pure" 768 ?
> b) some registers are already set by default or by bios
But when the bios forbids PM, takes it enough care to put them to the correct 
state ?
> c) some registers enable some extra savings
Another reason for a specialized driver.
> 
> >  I'm also using amd76x_pm and it's really wonderful, the CPUs cool down to 45C
> > from 75C, I can even stop the fans and the temp doesn't go above 60C if the
> > CPUs are idling.
> 
> See above. It doesn't do the right thing, especially not using bus
> mastering (like video capturing cards).
Probably not, but for example the previous version of the driver with C3 enabled
(the current version seems not to contain C3 support) entered C3 in my case
regularly (less than C2, but my machine is running a lot of daemons keeping CPU
load at 0.2 or more so maybe it didn't had enough time to enter it so often).
> 
                                        With regards, Pavel Troller



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

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

On Sat, 2005-09-10 at 19:08 +0200, Pavel Troller wrote:

> > a) mostly for the amd760 chipset (as opposed to amd768)

> But which chipset is in my machine, when for example lspci shows:
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System Controller (rev 11)
> 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP Bridge
> 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04)
> 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 04)
> Is it a compbination of 760/768 ? If the important part is in the first line, 
> does it mean that it cannot work that simple as a "pure" 768 ?

That actually is a amd768 chipset. The southbridge (in your case 768) is
what gives the chipset the name (btw I have exactly the same config).
The northbridge is always 760.

> > b) some registers are already set by default or by bios
> But when the bios forbids PM, takes it enough care to put them to the correct 
> state ?

I can change it in my bios settings.

> > c) some registers enable some extra savings
> Another reason for a specialized driver.

Ok, I guess you are right ;-) The default acpi driver lets one CPU go to
C3, one only to C1, and it looks like there actually doesn't happen
anything.

So I guess I will try amd76x_pm another try. Advantage is that I don't
use my saa7134 (tv capturing with extensive bus mastering) anymore, so
the busmastering latency isn't much an issue anymore.

Guess I'll have to give up the idea of plain acpi idling on SMP anyway.

> Probably not, but for example the previous version of the driver with C3 enabled
> (the current version seems not to contain C3 support) entered C3 in my case
> regularly (less than C2, but my machine is running a lot of daemons keeping CPU
> load at 0.2 or more so maybe it didn't had enough time to enter it so often).

The current version has an "extra" patch to add C3/NTH/POS support. The
latter two are imho actually not useful. I never got throttling working
(also by taking the except steps as described in the chipset docs), so I
guess it's broken; it won't buy you much power savings anyway. POS off
course is totally useless on a server system.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Erik Slagter]

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

On Sat, 2005-09-10 at 10:59 +0200, Janosch Machowinski wrote:
> > Is there a way to patch the FADT or to fool linux-acpi into it does
> > actually work (to at least be able to test the thing)?
> Shure, patch the verify functions in processor_idle.c ...
> But actually I think this is no good idea...

I tested it a few mins ago and there's good news and bad news ;-)

The very bad news is that my power meter is in a place I cannot reach at
the moment;

The good news is that CPU0 now has three C3 states and is almost
constantly running in that state;

The bad news is that CPU1 still reports only C1.

Could it be that the "restriction" of this chipset is, that the complete
system (including both cpu's) always must run in the same C-state? That
would be no real problem for me.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Janosch Machowinski]

Erik Slagter wrote:
> On Sat, 2005-09-10 at 10:59 +0200, Janosch Machowinski wrote:
> 
>>>Is there a way to patch the FADT or to fool linux-acpi into it does
>>>actually work (to at least be able to test the thing)?
>>
>>Shure, patch the verify functions in processor_idle.c ...
>>But actually I think this is no good idea...
> 
> 
> I tested it a few mins ago and there's good news and bad news ;-)
> 
> The very bad news is that my power meter is in a place I cannot reach at
> the moment;
> 
> The good news is that CPU0 now has three C3 states and is almost
> constantly running in that state;
> 
> The bad news is that CPU1 still reports only C1.
That's a bug:
Here a comment from ACPI Spec 3.0 :
Processor power state support is symmetric when presented via the FADT 
and P_BLK interfaces; OSPM
assumes all processors in a system support the same power states. If 
processors have non-symmetric power
state support, then the BIOS will choose and use the lowest common power 
states supported by all the
processors in the system through the FADT table. For example, if the 
CPU0 processor supports all power
states up to and including the C3 state, but the CPU1 processor only 
supports the C1 power state, then
OSPM will only place idle processors into the C1 power state (CPU0 will 
never be put into the C2 or C3
power states). Notice that the C1 power state must be supported. The C2 
and C3 power states are optional
(see the PROC_C1 flag in the FADT table description in section 5.2.6, 
“System Description Table
Header”).


Feel free to write a patch
> 
> Could it be that the "restriction" of this chipset is, that the complete
> system (including both cpu's) always must run in the same C-state? That
> would be no real problem for me.
No, every Processor can use the Sleep states independent (with some 
restrictions, see ACPISpec p. 257).


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: C states on AMD SMP

[Erik Slagter]

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

On Sat, 2005-09-10 at 14:47 +0200, Janosch Machowinski wrote:

> > The good news is that CPU0 now has three C3 states and is almost
> > constantly running in that state;
> > 
> > The bad news is that CPU1 still reports only C1.

> That's a bug:

[ ... ]

> Feel free to write a patch

I am sorry, that's way over my head. I am very much a newbie on ACPI
stuff.

Bummer!

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2115 bytes --]

Re: C states on AMD SMP

[Pavel Machek]

On Thu 08-09-05 13:29:16, Erik Slagter wrote:
> Hi,
> 
> I compiled & installed 2.6.13 (vanilla) on my Tyan Tiger S2466 (AMD768
> chipset, 2xathlon MP 2600) yesterday. Indeed, as expected, acpi
> "/proc/acpi/processor/*/power" (C states) is now supported on SMP. But,
> to my surprise, it only shows one C state (C1), which, I assume, is
> full-on.

Wrong. C1 is basically hlt.

				Pavel

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php