C states on AMD SMP

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.

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

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

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.

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

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

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

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 ;-)

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

Yes ;-)

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

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

Hi!

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 ?

But when the bios forbids PM, takes it enough care to put them to the correct state ?

Another reason for a specialized driver.

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

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.

I can change it in my bios settings.

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.

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.

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.

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

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

[ ... ]

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

Bummer!

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