linux-kernel - Re: Linux 2.6.33.8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 02 Apr 2011 23:08:27 +0200
From:	Carsten Emde <C.Emde@...dl.org>
To:	Len Brown <lenb@...nel.org>
CC:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Asit Mallick <asit.k.mallick@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Linux 2.6.33.8

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/