Bug 9488

Created attachment 13823 [details]
ACPI dump

Thomas Renninger asked me to add a acpi dump

Will you please attach the info using the following commands?
acpidump --addr 0xcf6dfdd2 --length 0x2bc -o cpu0ist
acpidump --addr 0xcf6e021a --length 0xb8  -o cpu1ist
acpidump --addr 0xcf6e02d2 --length 0x463 -o cpu0cst
acpidump --addr 0xcf6e0740 --length 0x47  -o cpu1cst
Thanks.

Created attachment 13835 [details]
acpi dumps as requested

The third length is wrong:
acpidump --addr 0xcf6e02d2 --length 0x463 -o cpu0cst
should be:
acpidump --addr 0xcf6e02d2 --length 0x46E -o cpu0cst

But anyway, this rather hard to debug. There are several functions playing with _PPC.
E.g.:
 - TCTR
 - TPTS
 - TWAK
 - ...

But when, why and whether it is intended that _PPC is increased is hard to debug. Maybe you should start with a BIOS update and going through your BIOS settings then. Search for anything related to speedstep/cpufreq/cpu power policy or whatever.

Hi, Michael
Thanks for the info. 
Will you please enable the debug function of cpufreq amd acpi in kernel configuration and boot the system with the option of acpi.debug_layer=0x01000000 acpi.debug_level=0x1f? 
After the system is booted and acpi_cpufreq driver is loaded, echo 2 > /sys/module/cpufreq/parameters/debug and echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor.

After the above is executed, do the folliwng actions.
a. cd /sys/devices/system/cpu/cpu/cpu0/cpufreq
b. cat scaling_max_freq > scaling_setspeed
c. cat 1600000 > scaling_setspeed
d. attach the output of dmesg.
Thanks.
 

I executed the above steps, see attached dmesg output. From what I can see, I don't think it will be of much help :-(

as soon as I loaded the acpi_cpufreq module, frequency goes down from 2.4 GHz to 2 GHz, and scaling_max_frequency is at 2000000, too (while cpuinfo_max_freq stays at 2400000).

To answer Thomas' questions: I already installed the latest BIOS 1.08 from Fujitsu Siemens; and there is only one BIOS setting regarding SpeedStep, If I disable SpeedStep at all, I can't even load the acpi_cpufreq module

Created attachment 14145 [details]
dmesg output

Created attachment 14200 [details]
test the debug patch

 >acpi-cpufreq: acpi_cpufreq_target 1600000 (0)
From the log in comment #7 it seems that this is a cpufreq-governor/policy problem  rather than _PPC problem.
Will you please try the debug patch in comment #7 and boot the system with the option of cpufreq.debug=7?
Thanks.

I applied ykzhao's debug patch, and booted with cpufreq.debug=7, see attached syslog.

Note that the first "PPC limit is 1" message appears *before* acpi_cpufreq was loaded!

Created attachment 14213 [details]
syslog with cpufreq.debug=7 and PPC debug

HI, Michael
Thanks for you log.
From the logs in comment #7 and #11 it seems that the system can work well when the governor of performance or userspace is used. 

Will you please try the following test after the system is booted?
a. echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
b. After about ten minutes , please attach the output of dmesg. The system load had better be increased or decreased frequently in the test.
Of course the debug patch and boot option of pufreq.debug=7 are still required.

Thanks.

> Note that the first "PPC limit is 1" message appears *before* acpi_cpufreq
> was loaded!
That looks normal. Your BIOS provides really strange values, but it should work:
merlin kernel: acpi-cpufreq:      *P0: 2401 MHz, 35000 mW, 10 uS
merlin kernel: acpi-cpufreq:       P1: 2400 MHz, 35000 mW, 10 uS
merlin kernel: acpi-cpufreq:       P2: 2000 MHz, 28000 mW, 10 uS
merlin kernel: acpi-cpufreq:       P3: 1600 MHz, 22000 mW, 10 uS
merlin kernel: acpi-cpufreq:       P4: 1200 MHz, 16000 mW, 10 uS
merlin kernel: acpi-cpufreq:       P5: 800 MHz, 14000 mW, 10 uS
The first (2401 MHz) seem to be some kind of dummy. The BIOS tells the OS to not use it by passing _PPC == 1.
This is rather obscure and I could imagine the problem is somehow related.

From comment #5 and #6 (and dmesg from comment #7):
> as soon as I loaded the acpi_cpufreq module, frequency goes down from 2.4 GHz
> to 2 GHz, and scaling_max_frequency is at 2000000, too...
There already something goes wrong:
  - From dmesg, cpufreq layer still seem to think it's at 2.4 (better pass
    cpufreq.debug=7 as boot parameter, instead of
    echo 2 >/sys/module/cpufreq/parameters/debug
    If something goes wrong at driver load time, we might see it then)


You might already want to try this quick shot and revert this patch:
commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e
(Copy and Pasted):
index 5207f9e..cbb6f08 100644 (file)
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -322,10 +322,6 @@ static int acpi_processor_get_performance_info(struct acpi_processor *pr)
        if (result)
                return result;
 
-       result = acpi_processor_get_platform_limit(pr);
-       if (result)
-               return result;
-
        return 0;
 }


This patch invokes _PPC at cpufreq init time, maybe it is needed on your machine, for more details:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e4233dec749a3519069d9390561b5636a75c7579

Anyway, the info ykzhao requested in comment #12 would also be very helpful, but better use cpufreq.debug=7 boot parameter to enable cpufreq debug.

Created attachment 14232 [details]
dmesg output

dmesg output, booted with cpufreq.debug=7 and acpi.debug_layer=0x01000000
acpi.debug_level=0x1f

The system was idle after boot, at 07:16:00 I run two instances of cpuburn (burnP6) in parallel. As you can see from dmesg, the cpu is already at 800 MHz and the frequency will not increase (in fact, nothing happens in dmesg after 07:15:30)

next I will give Thomas' patch a try, and post the dmesg here again.

I reverted the patch from comment #13 as supposed by Thomas, but it didn't help. Same behaviour as before (PPC increases, frequency decreases and will never increase again)

But I found a very quick and dirty solution for my problem: I applied the "ignore_ppc" patch from http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg06781.html and added the ignore_ppc option, now my system works as expected! I get clean frequency scaling.

Anyway, I know that this not a generic solution, So I'm willing to to some more debugging and testing...

re: processor.ignore_ppc

Wups, looks like I dropped that one and it is indeed useful:-(
Thomas, is it okay if i call it processor.noppc to be consistent
with the existing processor.nocst?

re: P0: 2401 MHz, P1: 2400 MHz

This is the mechanism to enable Intel Dynamic Acceleration Technology
on processors that support it. eg. the processor is guaranteed to be
able to do 2400 MHz, but may be able to run faster if the system provides
thermal and electrical headroom.

As there is no guarantee that P0 will be any faster than P1,
a 1MHz delta is used to describe the opportunistic upside.

Please check if there are any BIOS SETUP options related to this,
or processor power management in general.  Also, please paste
the contents of /proc/cpuinfo

HI, Michael
   From the above logs it seems that the problem is related with the _PPC value and is caused by the broken BIOS. 
   With the increment of _PPC limit, the cpufreq is decreased. But the _PPC value can't be decreased, so it seems that the cpu is locked at the 800MHz(the lowest performance P-state).
   
   It is appropriate to fix this issue by bios update. Of course it can be fixed by workaround patch(adding the module parameter of processor.noppc).

workaround shipped in 2.6.25-rc1 - closed.

commit 623b78c39c4525731f852072edd742cc4fba6786
Author: Thomas Renninger <trenn@suse.de>
Date:   Fri May 18 21:59:28 2007 -0500

    ACPI: add "processor.ignore_ppc" hook to workaround BIOS _PPC weirdness