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]
Message-ID: <4EB73E36.1040602@kernel.org>
Date:	Sun, 06 Nov 2011 21:11:02 -0500
From:	Len Brown <lenb@...nel.org>
To:	"Yu, Fenghua" <fenghua.yu@...el.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	H Peter Anvin <hpa@...or.com>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	"Luck, Tony" <tony.luck@...el.com>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/8] x86, topology.c: Enable CPU0 online/offline

On 11/03/2011 06:47 PM, Yu, Fenghua wrote:

>>> +	bsp_hotplug	[X86] BSP (aka CPU0) is hotpluggable.
>>> +			Suspend/resume depends on BSP. It's said some PCI
>>> +			quirks depend on BSP too. But not sure which quirks.
>>
>> Right, not sure what breaks. Go ahead and watch your machine explode.
>>
>>> +			If don't care the dependencies, you can turn on
>>> +			bsp_ hotplug. Suspend will fail if BSP is offlined
>> and
>>> +			you need to online BSP before suspend/resume.
>>
>> And you forgot poweroff and reboot, which have similar dependencies on
>> some machines. That whole low level ACPI stuff is sensitive.
> 
> I tested poweroff, shutdown, and reboot with various reboot_type on a few different platforms. I haven't seen poweroff and reboot issues after CPU0 is offline.
> 
> Do you have specific platforms that I can test poweroff and reboot dependency on CPU0?

> Or we just assume there are some platforms out there that depend on CPU0 for poweroff/reboot?

A classic Linux/ACPI failure happened when HT first shipped.
Some platforms stopped powering off or rebooting 50% of the time.

It turned out that SMM on those machines assumed
it would be triggered from CPU0 and not CPU1.

the original code should have worked, of course,
and most of the time it did -- but some systems broke.
The same will probably happen here.

-Len
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ