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. |
Description
Ariel T. Glenn
2005-09-22 13:35:36 UTC
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 |