Bug 84711 - deep C state not available - Samsung 535U3C, AMD A4-4355M
Summary: deep C state not available - Samsung 535U3C, AMD A4-4355M
Status: CLOSED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Xing Zhengjun
URL:
Keywords:
: 69551 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-17 07:54 UTC by Dennis Jansen
Modified: 2014-12-02 11:54 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.17-rc4
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg 3.13 (71.89 KB, application/octet-stream)
2014-09-17 07:54 UTC, Dennis Jansen
Details
acpidump (from version 20140214-64) (192.00 KB, text/plain)
2014-09-17 07:55 UTC, Dennis Jansen
Details
dmesg 3.17-rc4 (49.63 KB, text/plain)
2014-09-17 08:35 UTC, Dennis Jansen
Details
dmesg 3.17-rc4 without nocst=1 (61.09 KB, application/octet-stream)
2014-09-24 07:45 UTC, Dennis Jansen
Details
dmesg 3.0.101 (47.09 KB, text/plain)
2014-09-24 08:10 UTC, Dennis Jansen
Details
dmesg 3.0.101 nocst=1 (47.32 KB, text/plain)
2014-09-24 08:11 UTC, Dennis Jansen
Details
dmesg 3.15-rc2 with ACPI processor debug (55.08 KB, text/plain)
2014-09-28 10:10 UTC, Dennis Jansen
Details

Description Dennis Jansen 2014-09-17 07:54:59 UTC
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.
Comment 1 Dennis Jansen 2014-09-17 07:55:39 UTC
Created attachment 150611 [details]
acpidump (from version 20140214-64)
Comment 2 Dennis Jansen 2014-09-17 08:35:18 UTC
Created attachment 150621 [details]
dmesg 3.17-rc4
Comment 3 Xing Zhengjun 2014-09-23 02:00:24 UTC
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.
Comment 4 Dennis Jansen 2014-09-24 07:44:36 UTC
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.
Comment 5 Dennis Jansen 2014-09-24 07:45:11 UTC
Created attachment 151721 [details]
dmesg 3.17-rc4 without nocst=1
Comment 6 Dennis Jansen 2014-09-24 07:50:42 UTC
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?
Comment 7 Dennis Jansen 2014-09-24 08:09:48 UTC
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
Comment 8 Dennis Jansen 2014-09-24 08:10:45 UTC
Created attachment 151731 [details]
dmesg 3.0.101
Comment 9 Dennis Jansen 2014-09-24 08:11:07 UTC
Created attachment 151741 [details]
dmesg 3.0.101 nocst=1
Comment 10 Dennis Jansen 2014-09-24 08:22:59 UTC
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
Comment 11 Dennis Jansen 2014-09-24 08:24:28 UTC
Any further hints for kernels to try is welcome.
Comment 12 Xing Zhengjun 2014-09-28 07:59:18 UTC
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);
		}
.............
}
////////////////////////////////////////////
Comment 13 Dennis Jansen 2014-09-28 10:09:19 UTC
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.
Comment 14 Dennis Jansen 2014-09-28 10:10:44 UTC
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.
Comment 15 Dennis Jansen 2014-09-28 15:25:55 UTC
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;
	}
Comment 17 Dennis Jansen 2014-09-28 20:54:25 UTC
Now the problem is I don't know the C2, C3 latency times for my CPU.
Comment 18 Xing Zhengjun 2014-09-29 01:13:23 UTC
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.
Comment 19 Dennis Jansen 2014-09-29 06:09:10 UTC
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?
Comment 20 Zhang Rui 2014-09-29 06:49:30 UTC
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.
Comment 21 Dennis Jansen 2014-09-29 09:27:15 UTC
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
Comment 22 Zhang Rui 2014-12-02 11:54:58 UTC
*** Bug 69551 has been marked as a duplicate of this bug. ***

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