Created attachment 150601 [details] dmesg 3.13 Might be an ACPI issue as in #69551. cat /sys/devices/system/cpu/cpuidle/current_driver none attaching dmesg for 3.13 and 3.17 and acpidump.
Created attachment 150611 [details] acpidump (from version 20140214-64)
Created attachment 150621 [details] dmesg 3.17-rc4
Could you try booting with and without the intel_idle.max_cstate=0 and processor.nocst=1 kernel parameters, and provide kernel logs and test results as #69551 do? Thanks.
As this is an AMD CPU, should I really boot with any intel_idle parameters? I'm attaching a log without processor.nocst=1. But the system latency seems higher without that parameter. It's especially noticeable in X.
Created attachment 151721 [details] dmesg 3.17-rc4 without nocst=1
As to test results: I did reset my BIOS to optimum settings. There are no updates available for my BIOS. I have already attached my acpidump. Could you be more specific what tests you mean? Maybe you mean grep . /sys/devices/system/cpu/cpuidle/* /sys/devices/system/cpu/cpuidle/current_driver:1:none /sys/devices/system/cpu/cpuidle/current_governor_ro:1:menu or dmesg | grep idle 210:[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. 282:[ 0.192563] cpuidle: using governor ladder 283:[ 0.192572] cpuidle: using governor menu That's for all kernels and no matter what the boot parameter. Do you want me to try to boot a very old kernel like 2.6.38?
Oh yes, fascinating. I've tested 3.0 and it loads acpi-idle. Attaching dmesg. dmesg|grep idle in 3.0.101-0300101-generic: 179:[ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. 592:[ 1.108413] ACPI: acpi_idle registered with cpuidle 648:[ 1.312304] cpuidle: using governor ladder 649:[ 1.312349] cpuidle: using governor menu
Created attachment 151731 [details] dmesg 3.0.101
Created attachment 151741 [details] dmesg 3.0.101 nocst=1
I guess the problem must be somewhere here: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/acpi/processor_idle.c
Any further hints for kernels to try is welcome.
in Linux 3.0.101 acpi_idle diver will keep loaded even when ACPI is not running, so you can find "acpi_idle registered with cpuidle". /////////////////////////////////////////// drivers/acpi/processor_driver.c: /* * We keep the driver loaded even when ACPI is not running. * This is needed for the powernow-k8 driver, that works even without * ACPI, but needs symbols from this driver */ static int __init acpi_processor_init(void) { int result = 0; if (acpi_disabled) return 0; memset(&errata, 0, sizeof(errata)); if (!cpuidle_register_driver(&acpi_idle_driver)) { printk(KERN_DEBUG "ACPI: %s registered with cpuidle\n", acpi_idle_driver.name); } else { printk(KERN_DEBUG "ACPI: acpi_idle yielding to %s\n", cpuidle_get_driver()->name); } ............. } //////////////////////////////////// in Linux 3.17-rc4, code has been changed, acpi_idle driver loaded in API acpi_processor_power_init() of file drivers/acpi/processor_idle.c. Could you add logs in the API to debug step by step? Thanks. /////////////////////////////////// drivers/acpi/processor_idle.c int acpi_processor_power_init(struct acpi_processor *pr){ ............. /* * Install the idle handler if processor power management is supported. * Note that we use previously set idle handler will be used on * platforms that only support C1. */ if (pr->flags.power) { /* Register acpi_idle_driver if not already registered */ if (!acpi_processor_registered) { acpi_processor_setup_cpuidle_states(pr); retval = cpuidle_register_driver(&acpi_idle_driver); if (retval) return retval; printk(KERN_DEBUG "ACPI: %s registered with cpuidle\n", acpi_idle_driver.name); } ............. } ////////////////////////////////////////////
I'm attaching a dmesg with lots of debug log info about ACPI. I guess the interesting part might be C2 latency too large: 3137:[ 3.086931] processor_throttling-1189 processor_get_throttli: pblk_address[0x00000810] duty_offset[1] duty_width[3] 3140:[ 3.087044] processor_throttling-1235 processor_get_throttli: Found 8 throttling states 3141:[ 3.087171] processor_throttling-0711 processor_get_throttli: Throttling state is T0 (1000% throttling applied) 3142:[ 3.087267] processor_idle-0297 processor_get_power_in: C2 latency too large [101] 3143:[ 3.087341] processor_idle-0308 processor_get_power_in: C3 latency too large [1001] 3144:[ 3.087421] processor_idle-0316 processor_get_power_in: lvl2[0x00000000] lvl3[0x00000000] ... 3162:[ 3.098958] processor_throttling-0219 processor_throttling_i: Assume no T-state coordination The pr->flags.power is never set. So acpi-idle never loads.
Created attachment 152021 [details] dmesg 3.15-rc2 with ACPI processor debug Please let me know if that's what you need or if I can provide any other information. Unfortunately, I don't have a kernel source for 3.17 at the moment and no fast internet.
Ok, so it's indeed the lines 291 following of the code, which cause the states to be disabled, as the log above #13 suggests. I've tried removing this check and the C-states were recognized. But they are still not used by the system. /* * FADT specified C2 latency must be less than or equal to * 100 microseconds. */ if (acpi_gbl_FADT.c2_latency > ACPI_PROCESSOR_MAX_C2_LATENCY) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "C2 latency too large [%d]\n", acpi_gbl_FADT.c2_latency)); /* invalidate C2 */ pr->power.states[ACPI_STATE_C2].address = 0; } /* * FADT supplied C3 latency must be less than or equal to * 1000 microseconds. */ if (acpi_gbl_FADT.c3_latency > ACPI_PROCESSOR_MAX_C3_LATENCY) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "C3 latency too large [%d]\n", acpi_gbl_FADT.c3_latency)); /* invalidate C3 */ pr->power.states[ACPI_STATE_C3].address = 0; }
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/processor_idle.c#n291
Now the problem is I don't know the C2, C3 latency times for my CPU.
You have acpidump, use the following commands , you can get *.dsl file. sudo acpixtract -a acpi.dump sudo iasl -d *.dat in facp.dsl you can get C2, C3 latency [060h 0096 2] C2 Latency : 0065 [062h 0098 2] C3 Latency : 03E9 C2 Latency > 100, C3 latency > 1000, so pr->flags.power is not set and acpi-idle not loads.
OK, so the BIOS doesn't give valid latency times. So the C-states are disabled, so acpi-idle does not load. That could be because I could not find any C2 or C3 states for the CPU. But it does have C6 and CC6 states. (http://www.cse.psu.edu/~xydong/files/proceedings/ISLPED2012/docs/p367.pdf) How do I know if those states are used?
First of all, this is not a regression because although acpi_idle driver is loaded in 3.0, it does nothing because those C state are not actually used. Second, this is a firmware/hardware issue because they don't export valid C state for OS to use. Bug closed. BTW, I think you can check your BIOS options and see if the deep c-state is disabled in BIOS.
Agreed. It does not appear to be a regression at all. The problem seems to be with Samsung's BIOS, which does not properly enable C-states. I wonder if the C6 and CC6 states are used at all. Thank you for you help
*** Bug 69551 has been marked as a duplicate of this bug. ***