Bug 5294
| Summary: | manual throttling change ignored - Dell XPS Gen2 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Ariel T. Glenn (ariel) |
| Component: | Power-Thermal | Assignee: | Konstantin Karasyov (konstantin.karasyov) |
| Status: | REJECTED INSUFFICIENT_DATA | ||
| Severity: | normal | CC: | acpi-bugzilla |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.13-rc7 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
DSDT
config file for kernel dmidecode output /var/log/messages (with debugging) debug log: set throttling to T4, then T0, then T1. |
||
Created attachment 6090 [details]
DSDT
Created attachment 6091 [details]
config file for kernel
Created attachment 6092 [details]
dmidecode output
Created attachment 6093 [details]
/var/log/messages (with debugging)
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? 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
states:
*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.
Created attachment 6191 [details]
debug log: set throttling to T4, then T0, then T1.
Do this bug still persists on the latest kernel? 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. Ariel |
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 /proc/acpi/processor/.../throttling 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; build in CONFIG_APCI_PROCESSOR; echo 1 > /proc/acpi/processor/CPU0/throttling caat /proc/acpi/processor/CPU0/throttling It still shows state count: 8 active state: T0 states: *T0: 00% T1: 12% etc. 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 %d\n",value)); outl(value, pr->throttling.address); value = inl(pr->throttling.address); ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "checking after read: value is %d\n",value)); } 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?