On Monday, February 5, 2018 3:04:45 PM CET Ville Syrjälä wrote:

quoted

On Sun, Feb 04, 2018 at 10:18:07AM +0100, Rafael J. Wysocki wrote:

quoted

On Sun, Feb 4, 2018 at 10:12 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Mon, Jan 22, 2018 at 5:27 PM, Ville Syrjala
[off-list ref] wrote:

quoted

From: Ville Syrjälä <redacted>

This reverts commit 1b39e3f813b4685c7a30ae964d5529a1b0e3a286.

Makes my P3 machine oops somewhere in cpuidle. I suspect
CONFIG_ACPI=n may have something to do with this.

And if you don't do CONFIG_ACPI=n, does it still oops?

Don't think I actually tried that. I can give it a whirl tonight.

I think this machine should actually have ACPI, but it inherited
the .config from a P2 machine that did not. Apparently I was too
lazy to change .config when I swapped in the "new" machine.

I guess it would work, but never mind.

quoted

quoted

quoted

Anyway, there are later changes depending on this one, so reverting it
won't work in general.

Let me look deeper at this.

What's there in /sys/devices/system/cpu/cpuidle/current_driver on your
system with the problematic commit reverted?

# cat /sys/devices/system/cpu/cpuidle/current_driver
apm_idle

That is the key bit: I overlooked this little fellow.

Does the below (untested here) help?

---
 arch/x86/kernel/apm_32.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-pm/arch/x86/kernel/apm_32.c
===================================================================

--- linux-pm.orig/arch/x86/kernel/apm_32.c
+++ linux-pm/arch/x86/kernel/apm_32.c

@@ -2389,6 +2389,7 @@ static int __init apm_init(void)
 	if (HZ != 100)
 		idle_period = (idle_period * HZ) / 100;
 	if (idle_threshold < 100) {
+		cpuidle_poll_state_init(&apm_idle_driver);
 		if (!cpuidle_register_driver(&apm_idle_driver))
 			if (cpuidle_register_device(&apm_cpuidle_device))
 				cpuidle_unregister_driver(&apm_idle_driver);