AMD turion does not have support for c states

[jpittack]

This is a BIOS related issue. I have contacted my vendor, and they will not be providing support.

Any amd turion based system starts out of the box with out support for the deeper sleep c states. Only c0 and c1e are recognized. A turion is capable of c4.

As a result of this issue, my processor is drawing too much wattage, reducing battery life, increasing heat, and is running my fan non stop. P-states are working just fine. Using dynticks only makes this worse, but is another bug in itself, that until fixed, this issue will still exist.

Because many vendors will not provide support for the less popular amd processors, I hope that Ubuntu can help solve my woes.

Worth noting. Windows does not have support for this either. They change the voltage delivered to the processor as a workaround.

[maximilianhauser (maximilianhauser)]

Hello!

I have the same problem on my HP 9533eg with a AMD Turion tl-60. It is indifferent how idle the Laptop runs - it doesn't switch into any Powerstate.
uname -r says this: 2.6.24-18-generic

and this is the output from
cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: yes
power management: yes
throttling control: yes
limit interface: yes
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 8000 usec
states:
    C1: type[C1] promotion[--] demotion[--] latency[000] usage[00811488] duration[00000000000000000000]
    C2: type[C2] promotion[--] demotion[--] latency[005] usage[00000000] duration[00000000000000000000]
    C3: type[C3] promotion[--] demotion[--] latency[020] usage[00000000] duration[00000000000000000000]
state count: 8
active state: T0
state available: T0 to T7
states:
   *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%

throttling works perfect with powernowd but my main problem is the temperature of the cpu. It's always above 60 degrees and under heavy load it reaches 80 degrees.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[jakub007 (jozwicki)]

Newer laptops with AMD Turion X2 and AMD Athlon X2 mobile processors (which are
C1E capable) are overheating and have very degraded battery life due to bugs in
/usr/src/linux/drivers/acpi/processor_idle.c (not properly implemented C1
support).
C1E replaces C2 and C3 states, so BIOS usually doesn't have definitions for
_CST and PBLK in FADT - it is valid according to ACPI specification.

Here is MS info about PPM in Vista:
http://download.microsoft.com/download/0/0/b/00bba048-35e6-4e5b-a3dc-36da83cbb0d1/ProcPowerMgmt.docx

Below is patch which fixes C1 visibility, but doesn't increase battery life to
Vista level.

--- cut here --
--- kernels/linux-2.6.27-rc8/drivers/acpi/processor_idle.c 2008-09-30
00:24:02.000000000 +0200
+++ linux/drivers/acpi/processor_idle.c 2008-10-06 00:24:19.000000000 +0200
@@ -501,7 +501,7 @@
         * ------
         * Invoke the current Cx state to put the processor to sleep.
         */
- if (cx->type == ACPI_STATE_C2 || cx->type == ACPI_STATE_C3) {
+ if (cx->type >= ACPI_STATE_C1) {
                current_thread_info()->status &= ~TS_POLLING;
                /*
                 * TS_POLLING-cleared state must be visible before we
@@ -523,12 +523,17 @@
                 * Use the appropriate idle routine, the one that would
                 * be used without acpi C-states.
                 */
+
+ t1 = jiffies;
+
                if (pm_idle_save) {
                        pm_idle_save(); /* enables IRQs */
                } else {
                        acpi_safe_halt();
                        local_irq_enable();
                }
+
+ t2 = jiffies;

                /*
                 * TBD: Can't get time duration while in C1, as resumes
@@ -538,8 +543,7 @@
                 * Note: the TSC better not stop in C1, sched_clock() will
                 * skew otherwise.
                 */
- sleep_ticks = 0xFFFFFFFF;
-
+ sleep_ticks = ticks_elapsed(t1, t2);
                break;

        case ACPI_STATE_C2:
@@ -642,12 +646,13 @@
                return;
        }
        cx->usage++;
- if ((cx->type != ACPI_STATE_C1) && (sleep_ticks > 0))
+ if (cx->type != ACPI_STATE_C1 && sleep_ticks > 0)
                cx->time += sleep_ticks;

        next_state = pr->power.state;

 #ifdef CONFIG_HOTPLUG_CPU
+
        /* Don't do promotion/demotion */
        if ((cx->type == ACPI_STATE_C1) && (num_online_cpus() > 1) &&
            !pr->flags.has_cst && !(acpi_gbl_FADT.flags &
ACPI_FADT_C2_MP_SUPPORTED)) {
@@ -811,8 +816,11 @@
        if (!pr)
                return -EINVAL;

+ /* Newer dual-core CPUs use C1E instead of C2 and C3 and
+ * usually do not have _CST definitions or PBLK entries.
+ * ACPI specification allows for that so return zero here */
        if (!pr->pblk)
- return -ENODEV;
+ return 0;

        /* if info is obtained from pblk/fadt, type equals state */
        pr->power.states[ACPI_STATE_C2].type = ACPI_STATE_C2;
@@ -852,6 +860,11 @@
                pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
                pr->power.s...

[Zach (zwalters)]

I have the Ibex Beta (kernel 2.5.27-5 is the current kernel, I believe) running on my HP Pavilion dv6324us with the AMD Turion 64x2 processor. I also do not see any usage of c states beyond C1.

Output of cat /proc/acpi/processor/CPU0/* is as follows:

processor id: 0
acpi id: 0
bus mastering control: yes
power management: yes
throttling control: no
limit interface: no
<not supported>
active state: C0
max_cstate: C1
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
    C1: type[C1] promotion[--] demotion[--] latency[000] usage[02414989] duration[00000000000000000000]
    C2: type[C2] promotion[--] demotion[--] latency[005] usage[00000000] duration[00000000000000000000]
    C3: type[C3] promotion[--] demotion[--] latency[020] usage[00000000] duration[00000000000000000000]
<not supported>

[jpittack (john-pittack)]

Thanks for your responses. Sadly I don't know how to apply such a patch. I have not tried the new kernel, as I need a free weekend.

If you are saying a battery life improvement is to occur from this patch, won't dynticks need to work? I still have 250 wakeups in powertop.

[David Gaarenstroom (david-gaarenstroom)]

(@jakub007)
I had to rework the patch to make it work on the kernel tree, but where did you get this patch? I can't find it on the Linux kernel mailing-list, or even that *anybody* knows about this outside launchpad?!

It would be nice if a Kernel developer looked at this first and agreed with the patch and determined/confirmed the importance of this issue and submitted this to the vanilla kernel tree...

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Andy Whitcroft (apw)]

The patch is certainly not safe to apply generally in my opinion. Reading around the subject it appears that C1E should be supported in parallel with tickless, if its not enabling by default you should be able get it working usng the kernel command line parameter "hpet=force". If those of you who have this combination could test there and report back on this bug that woud be helpful.

[David Gaarenstroom (david-gaarenstroom)]

The patch is harmless, it only adds accounting for time in C1E, so that you can see in powertop, that your system is actually idle for e.g. 95% of the time. It does nothing besides that. C1E is supported just fine in a vanilla kernel, it has nothing to do with tickless (except that you cannot see the idle time in powertop on any system without tickless, but that's in general).
I think you're missing the point. It does not save any additional power, it just adds performance counters for it.

[delly (lol-to-hell)]

Well.......... i got a turion on my laptop myself, and the powermanagement does not work. The fan sounds like a jet engine, and it does not go down. The CPU is unable to go idle and stuff, which makes it unable to go down in tempratur, from when the PC is booted it will continue to slowly increase its tempratur.
Running Ubuntu 9.04 with standard generic Ubuntu kernel. cpufreq as deamon to regulare, with the autoload from cpufrqutils which should have made it work.

delly@delly-laptop:~$ cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: yes
power management: no
throttling control: yes
limit interface: yes
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
    C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000] duration[00000000000000000000]
state count: 8
active state: T0
state available: T0 to T7
states:
   *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%

delly@delly-laptop:~$ cat /proc/acpi/processor/CPU0/*
processor id: 0
acpi id: 0
bus mastering control: yes
power management: no
throttling control: yes
limit interface: yes
active limit: P0:T0
user limit: P0:T0
thermal limit: P0:T0
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
    C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000] duration[00000000000000000000]
state count: 8
active state: T0
state available: T0 to T7
states:
   *T0: 100%
    T1: 87%
    T2: 75%
    T3: 62%
    T4: 50%
    T5: 37%
    T6: 25%
    T7: 12%
delly@delly-laptop:~$ cat /proc/acpi/processor/CPU1/*
processor id: 1
acpi id: 1
bus mastering control: yes
power management: no
throttling control: no
limit interface: no
<not supported>
active state: C0
max_cstate: C8
bus master activity: 00000000
maximum allowed latency: 2000000000 usec
states:
<not supported>

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]