Re: Linux 2.6.33.8

[Carsten Emde]

On 04/02/2011 11:14 AM, Carsten Emde wrote:
> [..]
> CPU info:
> vendor_id : GenuineIntel
> cpu family : 6
> model : 44
> model name : Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz
> stepping : 2
>
> This is the situation:
>
> 1. Without commit ea53069231f9317062910d6e772cca4ce93de8c8:
> Everything is fine. The system correctly powers off.
>
> 2. With commit ea53069231f9317062910d6e772cca4ce93de8c8:
> a) Frequency scaling never enabled (acpi_cpufreq not loaded,
> cpufreq_ondemand not loaded):
> Everything is fine. The system correctly powers off.
> b) Frequency scaling enabled (acpi_cpufreq loaded, cpufreq_ondemand
> loaded) or
> c) Frequency scaling enabled and disabled (acpi_cpufreq still loaded
> since it cannot be removed easily, cpufreq_ondemand no longer
> loaded) or
> d) Frequency scaling enabled and disabled (acpi_cpufreq unloaded
> with force, cpufreq_ondemand no longer loaded):
> Not powering off, message:
> ACPI: Preparing to enter system sleep state S5
> Disabling non-boot CPUs ...
>
> In a next step, I will debug arch/x86/kernel/smpboot.c to find out why
> mwait_play_dead() returns when frequency scaling was not enabled and why
> it does not after it was enabled.
This assumption was incorrect. After inserting a number of debug outputs 
to kernel_power_off(), native_play_dead() and mwait_play_dead(), it 
turns out that the initial code path in case of the correct poweroff and 
the failed poweroff is identical:

    Frequency scaling                      Frequency scaling
      never enabled                      enabled and disabled

     kernel_power_off()                  kernel_power_off()
     "ACPI: Preparing to enter           "ACPI: Preparing to enter
       system sleep state S5"              system sleep state S5"
     kernel_power_off()                  kernel_power_off()
     "Disabling non-boot CPUs ..."       "Disabling non-boot CPUs ..."

1    native_play_dead()              1   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

2    native_play_dead()              2   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

3    native_play_dead()              3   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

4    native_play_dead()              4   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

5    native_play_dead()              5   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

6    native_play_dead()              6   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

7    native_play_dead()              7   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

8    native_play_dead()              8   native_play_dead()
     mwait_play_dead()                   mwait_play_dead()

9    native_play_dead()
     mwait_play_dead()

10   native_play_dead()
     mwait_play_dead()

11   native_play_dead()
     mwait_play_dead()

     kernel_power_off()
     "PM: Calling mce_shutdown"
     "PM: Calling i8259A_shutdown"
     kernel_power_off()
     "Power down."
     kernel_power_off()

Apparently, the system hangs after eight CPUs have been disabled. I'll 
try to provide some more debugging information. Does anybody out there 
have any idea what's going on?

	-Carsten.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/