Bug 5294 - manual throttling change ignored - Dell XPS Gen2
manual throttling change ignored - Dell XPS Gen2
Product: ACPI
Classification: Unclassified
Component: Power-Thermal
i386 Linux
: P2 normal
Assigned To: Konstantin Karasyov
Depends on:
  Show dependency treegraph
Reported: 2005-09-22 13:35 UTC by Ariel T. Glenn
Modified: 2006-10-20 10:04 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.13-rc7
Tree: Mainline
Regression: ---

DSDT (69.52 KB, text/plain)
2005-09-22 13:37 UTC, Ariel T. Glenn
config file for kernel (19.50 KB, text/plain)
2005-09-22 13:41 UTC, Ariel T. Glenn
dmidecode output (11.95 KB, text/plain)
2005-09-22 13:42 UTC, Ariel T. Glenn
/var/log/messages (with debugging) (99.54 KB, text/plain)
2005-09-22 13:47 UTC, Ariel T. Glenn
debug log: set throttling to T4, then T0, then T1. (7.87 KB, text/plain)
2005-09-29 16:45 UTC, Ariel T. Glenn

Description Ariel T. Glenn 2005-09-22 13:35:36 UTC
Distribution: Fedora core 4, but using vanilla 2.6.13-rc7 kernel
Hardware Environment: Dell XPS Gen2 laptop
Software Environment: booted single user, running syslog but no other services
Problem Description:
On my hardware, writing a new throttling state to
silently fails.  When I check the throttling state by reading the same
file, the active throttling state is T0. 

Steps to reproduce:

Have one of these laptops; 
echo 1 > /proc/acpi/processor/CPU0/throttling
caat /proc/acpi/processor/CPU0/throttling
It still shows 

state count:             8
active state:            T0
   *T0:                  00%
    T1:                  12%


I got desperate enough to add debugging to processor_throttling.c
In particular, in acpi_processor_set_throttling(), I added debugging to the part
where the state gets written:

        if (state) {
                value &= duty_mask;
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "value is %d\n",value));
                value |= duty_value;
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "value is now %d\n",value));
                outl(value, pr->throttling.address);

                value |= 0x00000010;
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "value is now finally
                outl(value, pr->throttling.address);

                value = inl(pr->throttling.address);
                ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "checking after read: value is

The output I get is: 

acpi_processor-0183 [08] acpi_processor_set_thr: value is 0
acpi_processor-0185 [08] acpi_processor_set_thr: value is now 14
acpi_processor-0189 [08] acpi_processor_set_thr: value is now finally 30
acpi_processor-0193 [08] acpi_processor_set_thr: checking after read: value is 0

There seems to be a good Processor definition in the DSDT using \_PR.CPU0
CPU power and performance states change ok.
What am I missing here?
Comment 1 Ariel T. Glenn 2005-09-22 13:37:43 UTC
Created attachment 6090 [details]
Comment 2 Ariel T. Glenn 2005-09-22 13:41:21 UTC
Created attachment 6091 [details]
config file for kernel
Comment 3 Ariel T. Glenn 2005-09-22 13:42:44 UTC
Created attachment 6092 [details]
dmidecode output
Comment 4 Ariel T. Glenn 2005-09-22 13:47:52 UTC
Created attachment 6093 [details]
/var/log/messages (with debugging)
Comment 5 Len Brown 2005-09-28 18:59:04 UTC
hmmm, looks like that inl() should have worked.
maybe something else wrote to it.

build with CONFIG_ACPI_DEBUG and enable
"acpi_dbg_level=0xffffffff acpi_dbg_layer=0x01000000"
at boot-time or in /proc/acpi/
The first one turns on everything. the second turns
it on only for processor related things.

Also, if you can run a cpu-benchmark to see if the
system is really throttling, or just reporting the
throttling incorrectly?
Comment 6 Ariel T. Glenn 2005-09-29 16:39:52 UTC
benchmarks were useful' they show that throttling state did change.  (However, I
can't change it back to T0 ever, because the system thinks it's already in that
state.  I can change it to any other state even if that change is not reported.)

I saw nothing useful in the log after enabling the appropriate debug_layer.  

Here's the sequence of steps I took:

1. boot single user, start syslog
2. verify that there is no cpu frequency management happening
3. run benchmark
4. look at /proc/acpi/processor/CPU0/throttling
5. set debug_level and debug_layer
6. echo 4 > /proc/acpi/processor/CPU0/throttling
7. look at /proc/acpi/processor/CPU0/throttling  (unchanged)
8. set debug_level to 0
9. run benchmark  (shows 50% speed, as it should)
10. set debug_level to 0x01000000
11. echo 0 > /proc/acpi/processor/CPU0/throttling
12. set debug_level to 0
13. run benchmark (still shows 50% speed)
14. set debug_level to 0x01000000
15. echo 1 > /proc/acpi/processor/CPU0/throttling
16. set debug_level to 0
17. run benchmark (shows 10% or so reduction as it should)
18. look at /proc/acpi/processor/CPU0/throttling (unchanged)

Here are the benchmark results (first few lines only). I used nbench 2.2.2.

before messing with throttling --
NUMERIC SORT        :          993.44  :      25.48  :       8.37
STRING SORT         :          87.085  :      38.91  :       6.02
BITFIELD            :       3.197e+08  :      54.84  :      11.45

after setting to T4 --
NUMERIC SORT        :           439.2  :      11.26  :       3.70
STRING SORT         :          38.308  :      17.12  :       2.65
BITFIELD            :      1.4131e+08  :      24.24  :       5.06

after setting to T0 --
NUMERIC SORT        :          440.16  :      11.29  :       3.71
STRING SORT         :          38.403  :      17.16  :       2.66
BITFIELD            :      1.4198e+08  :      24.35  :       5.09

after setting to T1 --
NUMERIC SORT        :          796.48  :      20.43  :       6.71
STRING SORT         :          70.476  :      31.49  :       4.87
BITFIELD            :      2.5922e+08  :      44.47  :       9.29

/proc/acpi/processor/CPU0/throttling always had this content in it:
state count:             8
active state:            T0
   *T0:                  00%
    T1:                  12%
    T2:                  25%
    T3:                  37%
    T4:                  50%
    T5:                  62%
    T6:                  75%
    T7:                  87%

I'll include the relevant part of the log in the next attachment.
Most of it is debugging messages I added before reporting this bug.

I also ran this test (without CONFIG_ACPI_DEBUG) under the stock FC4 kernel
which these days is 2.6.12-1.1456_FC4 and saw the same behavior; this was just a
check to make sure my debugging messages in 2.6.13-rc7 hadn't broken anything.
Comment 7 Ariel T. Glenn 2005-09-29 16:45:24 UTC
Created attachment 6191 [details]
debug log: set throttling to T4, then T0, then T1.
Comment 8 Konstantin Karasyov 2006-06-07 03:26:22 UTC
Do this bug still persists on the latest kernel?
Comment 9 Anonymous Emailer 2006-06-09 17:08:02 UTC
Reply-To: ariel@columbia.edu

> ------- Additional Comments From konstantin.a.karasyov@intel.com  2006-06-07 03:26 -------
> Do this bug still persists on the latest kernel?

I'll have to check.  It will be a little while before I can tell you
because I go for surgery soon and will be a little while recovering.
Then I can do some testing.


Note You need to log in before you can comment on or make changes to this bug.