Hi,
Some device drivers register CPU hotplug notifiers and use them to destroy

device objects when removing the corresponding CPUs and to create these objects

when adding the CPUs back.
Unfortunately, this is not the right thing to do during suspend/hibernation,

since in that cases the CPU hotplug notifiers are called after suspending

devices and before resuming them, so the operations in question are carried

out on the objects representing suspended devices which shouldn't be

unregistered behing the PM core's back.  Although right now it usually doesn't

lead to any practical complications, it will predictably deadlock if

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch is applied.
The solution is to prevent drivers from removing/adding devices from within

CPU hotplug notifiers during suspend/hibernation using the FROZEN bit

in the notifier's action argument.  However, this has to be done with care,

since the devices objects related to the nonboot CPUs that failed to go online

during resume should not be present in the system.  For this reason, it seems

reasonable to introduce a mechanism allowing drivers to ask the PM core to

remove device objects corresponding to suspended devices on their behalf.
The first patch in the series introduces such a mechanism.  The remaining three

patches modify the MSR, x86-64 MCE and cpuid drivers in accordance with the

above approach.
Thanks,

Rafael
--

On Wed, 2 Jan 2008 00:32:44 +0100
These patches are a preresuisite to

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and its

later fixed-up versions.
So what I have now is
revert-gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

pm-introduce-destroy_suspended_device.patch

pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch

pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch

pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch

pm-acquire-device-locks-on-suspend-rev-3.patch

pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch

pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch
So what needs to happen in Greg's tree is
a) drop the old gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
b) apply these four patches
c) apply the new pm-acquire-device-locks-on-suspend-rev-3.patch (and its fixups)
--

On Fri, 11 Jan 2008 16:46:13 -0800
err, no.  pm-introduce-destroy_suspended_device.patch demolishes

pm-acquire-device-locks-on-suspend-rev-3.patch
Confused, giving up.

--

Sorry, I didn't know you still had pm-introduce-destroy_suspended_device.patch.
Please drop:
pm-do-not-destroy-create-devices-while-suspended-in-msrc-rev-2.patch

pm-do-not-destroy-create-devices-while-suspended-in-mce_64c.patch

pm-do-not-destroy-create-devices-while-suspended-in-cpuidc.patch

pm-acquire-device-locks-on-suspend-rev-3.patch

pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes.patch

pm-acquire-device-locks-on-suspend-rev-3-checkpatch-fixes-2.patch
and I'll resend a new checkpatch.pl-compliant version of the

pm-acquire-device-locks-on-suspend patch with appropriate sign-offs to you

and Greg.

--

I'm confused too, I have no idea what the proper order of things should

be either.  Anyone want to give me a hint?
thanks,
greg k-h

--

Sorry for the confusion.  The correct patch to apply is

pm-acquire-device-locks-on-suspend-rev-3 (plus the attending

style-fixups).  It encompasses those earlier patches.
The real problem is that our current email workflow patterns don't

provide a standardized way for maintainers to tell when a new patch

submission is meant to override or replace an earlier submission (or

even a set of earlier submissions).  Does anybody have some suggestions

for a good way to do this?
Alan Stern
--

Can someone resend this to me?  Do I need to drop the patch I currently
Yeah, just tell me what you want me to do with it (drop an old one,

replace it, add it, etc.)  We usually can handle this pretty well :)
thanks,
greg k-h

--

I'll repost the new patch along with instructions what to do with it.
Greetings,

Rafael

--

Don't formally send it until it's ready.  Seriously.  You can always resend

it if it didn't get applied anywhere.
Once a patch reaches a sufficient level of maturity for it to be ready to

be merged into a subsystem tree, any subsequent changes should be

sufficiently small that incremental patches are the way to apply touchups.
The core problem here is that (lots of) people are flinging patches at

tree-owners before they are sufficiently baked.

--

The versioning approach pioneered by Christoph Lameter seems to work

reasonably well.
If you post a new version increase a version number and add it with "vXXX" to the

Subject.
Also add a short change log between versions at the bottom; e.g. v1->v2: .... etc.
Then it is always clear what is the latest'n'greatest.
-Andi

--

btw., it would be really, really cool if there was a scriptable way i

could test suspend/resume functionality. Pavel has this /dev/rtc thing

to set up an alarm (not sure how functional it is) - would it be

possible to have it as a "suspend for 10 seconds then resume" debug

functionality? That way any suspend breakage would be detectable (and

bisectable) in automated testing - if the resume does not come back

after 10-20 seconds then the test failed.
	Ingo

--

First, there are patches queued for 2.6.25 that allow you to test various

phases of suspend (specifically, patches 09-11 in the series at

http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/).
With these patches applied you can do something like:

# echo core > /sys/power/pm_test

# echo mem > /sys/power/state

and it will run the suspend code up to, but not including, entering the sleep

state (it will busy wait for 5 sec. instead).  Then, it will run the resume

code.
There are 6 testing levels available, documented in patch 11 and in the

changelogs.
Second, there's the rtc wakealarm thing that can be used to test the real
Well, we have the following test script in the userland suspend package that

is supposed to work right now:
#!/bin/bash

date

cd /sys/class/rtc/rtc0

echo $(( $(cat since_epoch) + 20 )) > wakealarm

s2ram

date
Yes, but please note that some systems require user space manipulations of the

graphics adapter for suspend to work and to detect a breakage of such a system

you need to boot it into X and use s2ram to suspend.
Greetings,

Rafael

--

(David Brownell Cc:-ed too)
ok, will try that. A stupid question. The old RTC driver is in

drivers/char/rtc.c, and maps to:
  crw-r--r-- 1 root root  10, 135 Oct 25 18:02 /dev/rtc
the new driver is in drivers/rtc/*, and maps to:
  crw-r--r-- 1 root root 254,   0 Dec 12 02:30 /dev/rtc0
but all the x86 distro boxes i have access to make use of /dev/rtc.

There's no symlink set up from /dev/rtc to /dev/rtc0 either. So it

appears to me that the new RTC driver isnt actually utilized on most

distributions.
shouldnt we provide a Kconfig way of replacing dev 10:135 with the new

driver's 254:0 device? (while keeping all the current modes of operation

as well, of course.) It's all supposed to be 100% ioctl ABI compatible

with the old driver, right? That way distros could start migrating to it 
yeah, i wouldnt expect graphics mode to come back without quirks. But it

should still work fine over the network, right? (which is my main mode

of testing anyway)
	Ingo

--

Eventually, swapping driver modules ought to work too.  The

legacy /proc/acpi/wakeup files would ISTR cause problems in

current code.
Of course, one reason to want to use the RTC framework code

is to stop depending on x86-isms like ACPI or "s2ram", and
Current util-linux-ng code uses either RTC device file; and udev

sets up /dev/rtc0 as needed.  (But not /dev/rtc, as I recall...)
That might be so.  There are some HPET issues, but those show up with

both drivers.
The main other issue I know about which would seem to argue for using

the legacy driver, instead of the RTC framework, is that some BIOSes

don't seem to provide PNPACPI entries for their RTCs.  I got one report

of a newish HP Opteron system that doesn't.  I have no idea how common

that is.  The drivers/acpi/glue.c code could detect that, but maybe a

better place to address that would be in PNP code; in that case, ISTR

that PNP0c01 claimed the RTC ioports, and so would be the natural place
The major number 254 is not statically allocated, ISTR; that should
I don't know of any ioctl differences userspace would care about.
- Dave
--

sorry, i meant a .config option that would cause 10:135 to be managed by

the new RTC code too. (Config option can be default-off.)
	Ingo

--

It's not compatible enough to "fake" only the old major/minor. Userspace

must be fixed not to depend on stuff like:  /proc/sys/dev/rtc/max-user-freq:
It's in the default udev setup:

  KERNEL=="rtc|rtc0",             MODE="0644"

  KERNEL=="rtc0",                 SYMLINK+="rtc"
Kay

--

i think that should be fixed by providing a compatible 
but if it breaks max-user-freq (which is needed by qemu for example)

then distros would likely disable it, right?
or this rule might be broken in some way. For example my Fedora 8 box

has this in /etc/udev/rules.d/50-udev-default.rules:
 # miscellaneous

 KERNEL=="fuse",                 MODE="0666"

 KERNEL=="rtc|rtc0",             MODE="0644"

 KERNEL=="rtc0",                 SYMLINK+="rtc"
still i've got:
 crw------- 1 root root  10, 135 Dec 28 08:13 /dev/rtc

 crw-r--r-- 1 root root 254,   0 Dec 28 08:13 /dev/rtc0
_and_ my distro kernel doesnt even have CONFIG_RTC enabled - i run the

Fedora 9 devel/rawhide kernel on this box:
 # CONFIG_RTC is not set

 # CONFIG_GEN_RTC is not set

 # CONFIG_HPET_RTC_IRQ is not set

 CONFIG_RTC_LIB=y

 CONFIG_RTC_CLASS=y

 # CONFIG_RTC_HCTOSYS is not set

 # CONFIG_RTC_DEBUG is not set

 # RTC interfaces

 CONFIG_RTC_INTF_SYSFS=y

 CONFIG_RTC_INTF_PROC=y

 CONFIG_RTC_INTF_DEV=y

 # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

 # CONFIG_RTC_DRV_TEST is not set
udev-116-3.fc8. Maybe i just misunderstood what the grand plan was here

- i assumed it was to smoothly convert from old driver to new driver,

without forcing any changes on user-space.
	Ingo

--

I suspect the /dev/rtc node was provided by the distro, so those
I run my x86 systems like that (also with RTC_DRV_CMOS), but

the ARM systems usually have RTC_HCTOSYS set too (plus some

RTC driver other than rtc-cmos).  The x86 system init code
If there was a Grand Plan, I never heard of it. :)
It'd need to have some NTP sync solution for RTC_LIB devices, but

ISTR the gentime stuff still assumes an update_persistent_clock()

that doesn't sleep ... and hence can't be used with I2C based RTCs.
I've been trying to make sure the x86 world could realistically

switch to the RTC framework used by other Linux platforms, hence

e.g. the util-unix-ng updates, but never assumed there would be

no userspace changes.  After all, userspace was using a mishmash

of tools that were far from platform-agnostic, and moving away

from x86-dependency implies such things will change.
However I *do* think that symlinking rtc to /dev/rtc0 should

make it practical to use most older binaries.
- Dave
--

then please provide a kernel config option for the new driver to take

over 10:135 too. There's nothing worse to the adoption of new kernel

features necessiating user-space attention. I've got several images of

old distros that i dont want to reconfigure in any way, and it would be

nice to have a drop-in /dev/rtc replacement for them. Really. This is

how we do it for just about everything else too.
	Ingo

--

I'll let someone else chase that particular issue.  :)
--

On Wed, 02 Jan 2008 09:54:00 -0800
 I still believe NTP sync stuff should be done outside of the kernel.

 given the mean accuracy of RTC chips and other sync factors, imho

 you haven't so much to gain with an in-kernel sync code.
-- 
 Best regards,
 Alessandro Zummo,

  Tower Technologies - Torino, Italy
  http://www.towertech.it
--

Then the kernel/time/ntp.c stuff should be removed on all systems?

--

On Wed, 02 Jan 2008 10:12:54 -0800
 I'd say yes, but I think that would be dangerous to my own life :)
-- 
 Best regards,
 Alessandro Zummo,

  Tower Technologies - Torino, Italy
  http://www.towertech.it
--

Well, if the graphics is sufficiently broken, it won't resume at all.
The "echo core > /sys/power/pm_test && echo mem > /sys/power/state" thing

should always work, though (IOW, if this doesn't work, we cartainly have a

bug).
Rafael

--

Actually, no. Unless you try to boot the bios, it should come up

without graphics. 
Hmm... first framebuffer access may kill the machine at that

point... so disable framebuffer...? ;-). 
vga=1 and no acpi_sleep options usually does the trick for me. That

should work everywhere, independend of graphics options, AFAICT.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

From: Rafael J. Wysocki <rjw@sisk.pl>
The MSR driver should not attempt to destroy/create a device while

suspended, unless this device corresponds to a nonboot CPU that

failed to go online during a resume, in which case the PM core should

be asked to remove it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/x86/kernel/msr.c |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/kernel/msr.c

===================================================================

--- linux-2.6.orig/arch/x86/kernel/msr.c

+++ linux-2.6/arch/x86/kernel/msr.c

@@ -155,15 +155,15 @@ static int __cpuinit msr_class_cpu_callb
 	switch (action) {

 	case CPU_UP_PREPARE:

-	case CPU_UP_PREPARE_FROZEN:

 		err = msr_device_create(cpu);

 		break;

 	case CPU_UP_CANCELED:

-	case CPU_UP_CANCELED_FROZEN:

 	case CPU_DEAD:

-	case CPU_DEAD_FROZEN:

 		msr_device_destroy(cpu);

 		break;

+	case CPU_UP_CANCELED_FROZEN:

+		destroy_suspended_device(msr_class, MKDEV(MSR_MAJOR, cpu));

+		break;

 	}

 	return err ? NOTIFY_BAD : NOTIFY_OK;

 }
--

From: Rafael J. Wysocki <rjw@sisk.pl>
It sometimes is necessary to destroy a device object during a suspend or

hibernation, but the PM core is supposed to control all device objects in that

cases.  For this reason, it is necessary to introduce a mechanism allowing one

to ask the PM core to remove a device object corresponding to a suspended

device on one's behalf.
Define function destroy_suspended_device() that will schedule the removal of

a device object corresponding to a suspended device by the PM core during the

subsequent resume.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 drivers/base/core.c        |   44 +++++++++++++++++++++++++++++++++++++++-----

 drivers/base/power/main.c  |   36 +++++++++++++++++++++++++++---------

 drivers/base/power/power.h |    1 +

 include/linux/device.h     |    8 ++++++++

 4 files changed, 75 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/base/core.c

===================================================================

--- linux-2.6.orig/drivers/base/core.c

+++ linux-2.6/drivers/base/core.c

@@ -1156,14 +1156,11 @@ error:

 EXPORT_SYMBOL_GPL(device_create);
 /**

- * device_destroy - removes a device that was created with device_create()

+ * find_device - finds a device that was created with device_create()

  * @class: pointer to the struct class that this device was registered with

  * @devt: the dev_t of the device that was previously registered

- *

- * This call unregisters and cleans up a device that was created with a

- * call to device_create().

  */

-void device_destroy(struct class *class, dev_t devt)

+static struct device *find_device(struct class *class, dev_t devt)

 {

 	struct device *dev = NULL;

 	struct device *dev_tmp;

@@ -1176,12 +1173,49 @@ void device_destroy(struct class *class,

 		}

 	}

 	up(&class->sem);

+	return dev;

+}
+/**

+ * device_destroy - removes a device that was created with device_create()

+ * @class: pointer to the struct class that this device was registered w...
[ message continues ]

Sorry, a small fix is needed for this patch.  Namely, dpm_sysfs_remove(dev)

should not be called by device_pm_schedule_removal(), because it will be called

anyway from device_pm_remove() when the device object is finally unregistered

(we're talking here about unlikely error paths only, but still).
Corrected patch follows.
Thanks,

Rafael
---

From: Rafael J. Wysocki <rjw@sisk.pl>
It sometimes is necessary to destroy a device object during a suspend or

hibernation, but the PM core is supposed to control all device objects in that

cases.  For this reason, it is necessary to introduce a mechanism allowing one

to ask the PM core to remove a device object corresponding to a suspended

device on one's behalf.
Define function destroy_suspended_device() that will schedule the removal of

a device object corresponding to a suspended device by the PM core during the

subsequent resume.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 drivers/base/core.c        |   44 +++++++++++++++++++++++++++++++++++++++-----

 drivers/base/power/main.c  |   35 ++++++++++++++++++++++++++---------

 drivers/base/power/power.h |    1 +

 include/linux/device.h     |    8 ++++++++

 4 files changed, 74 insertions(+), 14 deletions(-)
Index: linux-2.6/drivers/base/core.c

===================================================================

--- linux-2.6.orig/drivers/base/core.c

+++ linux-2.6/drivers/base/core.c

@@ -1156,14 +1156,11 @@ error:

 EXPORT_SYMBOL_GPL(device_create);
 /**

- * device_destroy - removes a device that was created with device_create()

+ * find_device - finds a device that was created with device_create()

  * @class: pointer to the struct class that this device was registered with

  * @devt: the dev_t of the device that was previously registered

- *

- * This call unregisters and cleans up a device that was created with a

- * call to device_create().

  */

-void device_destroy(struct class *class, dev_t devt)

+static struct device *find_device(struct class *class...
[ message continues ]

The situation is a little confusing, because the source files under

drivers/base/power are maintained in Greg's tree and he already has

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

installed.  That patch conflicts with this one.
One of the these two patches will have to be rewritten to apply on top

of the other.  Which do you think should be changed?
Alan Stern
--

Well, from the bisectability point of view, it would be better to adjust

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch and let the

$subject patch series go first, if you don't mind.
Rafael

--

I have rebased gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

on top of the $subject series, the result is appended.  It has only been

compilation tested for now, but I'll be testing it for the next couple of days.
Please review.
Thanks,

Rafael
---

From: Alan Stern <stern@rowland.harvard.edu>, Rafael J. Wysocki <rjw@sisk.pl>
This patch reorganizes the way suspend and resume notifications are

sent to drivers.  The major changes are that now the PM core acquires

every device semaphore before calling the methods, and calls to

device_add() during suspends will fail.

---

 drivers/base/core.c        |   13 -

 drivers/base/power/main.c  |  452 ++++++++++++++++++++++++++-------------------

 drivers/base/power/power.h |   11 +

 3 files changed, 290 insertions(+), 186 deletions(-)
Index: linux-2.6/drivers/base/core.c

===================================================================

--- linux-2.6.orig/drivers/base/core.c

+++ linux-2.6/drivers/base/core.c

@@ -726,11 +726,17 @@ int device_add(struct device *dev)

 {

 	struct device *parent = NULL;

 	struct class_interface *class_intf;

-	int error = -EINVAL;

+	int error;

+

+	error = pm_sleep_lock();

+	if (error)

+		return error;
 	dev = get_device(dev);

-	if (!dev || !strlen(dev->bus_id))

-		goto Error;

+	if (!dev || !strlen(dev->bus_id)) {

+		error = -EINVAL;

+		goto Done;

+	}
 	pr_debug("DEV: registering device: ID = '%s'\n", dev->bus_id);
@@ -795,6 +801,7 @@ int device_add(struct device *dev)

 	}

  Done:

 	put_device(dev);

+	pm_sleep_unlock();

 	return error;

  BusError:

 	device_pm_remove(dev);

Index: linux-2.6/drivers/base/power/main.c

===================================================================

--- linux-2.6.orig/drivers/base/power/main.c

+++ linux-2.6/drivers/base/power/main.c

@@ -24,18 +24,39 @@

 #include <linux/mutex.h>

 #include <linux/pm.h>

 #include <linux/resume-trace.h>

+#include <linux/rwsem.h>
 #include "../base.h...
[ message continues ]

I would prefer it if you could also merge in this patch at the same

time:
With the aforementioned patch merged in, this will generate a

warning for each dropped device.  The call to

unregister_dropped_devices() should come after the up_write().
You might also consider adding a call to unregister_dropped_devices()

in the error path of device_suspend() -- in theory even an aborted

suspend might cause a device to malfunction.
Otherwise this looks okay.
Alan Stern
--

In fact it already works like this, since device_suspend() now calls the entire
However, I think we don't need to wait with unregistering suspended devices

until after the other ones are resumed.  We only need a special function for

unregistering suspended devices that will make the PM core release the device's

semaphore before unregistering it.
I have already sent a replacemet for

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that includes

some code from the $subject patch and implements the above idea:
http://lkml.org/lkml/2008/1/4/278
I'm going to merge it with your patch at:

https://lists.linux-foundation.org/pipermail/linux-pm/2007-December/0159...

and with patches [2/4] and [4/4] from the $subject series.  I'll post the

result for a review later today.
Thanks,

Rafael

--

Actually, please scratch that.  We can do better.
The appended patch (compilation tested) combines patch [1/4] with the

gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch in such a way

that it is now possible to remove a suspended device at once via the PM core

using the destroy_suspended_device() callback.
Thus, the drivers that need to remove device objects while suspended (eg.

from the CPU hotplug notifiers) can use destroy_suspended_device() for this

purpose without deadlocking, but using device_destroy() to remove suspended

devices is prohibited.
Please review.
Thanks,

Rafael
---

From: Alan Stern <stern@rowland.harvard.edu>, Rafael J. Wysocki <rjw@sisk.pl>
This patch reorganizes the way suspend and resume notifications are

sent to drivers.  The major changes are that now the PM core acquires

every device semaphore before calling the methods, and calls to

device_add() during suspends will fail.
It also provides a way to safely remove a suspended device with the help of

the PM core, by using the destroy_suspended_device() callback introduced

specifically for this purpose. 
Not-yet-signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 drivers/base/core.c        |   57 ++++-

 drivers/base/power/main.c  |  452 ++++++++++++++++++++++++++-------------------

 drivers/base/power/power.h |   12 +

 include/linux/device.h     |    8

 4 files changed, 336 insertions(+), 193 deletions(-)
Index: linux-2.6/drivers/base/core.c

===================================================================

--- linux-2.6.orig/drivers/base/core.c

+++ linux-2.6/drivers/base/core.c

@@ -726,11 +726,17 @@ int device_add(struct device *dev)

 {

 	struct device *parent = NULL;

 	struct class_interface *class_intf;

-	int error = -EINVAL;

+	int error;

+

+	error = pm_sleep_lock();

+	if (error)

+		return error;
 	dev = get_device(dev);

-	if (!dev || !strlen(dev->bus_id))

-		goto Error;

+	if (!dev || !strlen(dev->bus_id)) {

+		error = -EINVAL;

+		...
[ message continues ]

From: Rafael J. Wysocki <rjw@sisk.pl>
The cpuid driver should not attempt to destroy/create a device while

suspended, unless this device corresponds to a nonboot CPU that

failed to go online during a resume, in which case the PM core should

be asked to remove it.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/x86/kernel/cpuid.c |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpuid.c

===================================================================

--- linux-2.6.orig/arch/x86/kernel/cpuid.c

+++ linux-2.6/arch/x86/kernel/cpuid.c

@@ -157,15 +157,15 @@ static int __cpuinit cpuid_class_cpu_cal
 	switch (action) {

 	case CPU_UP_PREPARE:

-	case CPU_UP_PREPARE_FROZEN:

 		err = cpuid_device_create(cpu);

 		break;

 	case CPU_UP_CANCELED:

-	case CPU_UP_CANCELED_FROZEN:

 	case CPU_DEAD:

-	case CPU_DEAD_FROZEN:

 		cpuid_device_destroy(cpu);

 		break;

+	case CPU_UP_CANCELED_FROZEN:

+		destroy_suspended_device(cpuid_class, MKDEV(CPUID_MAJOR, cpu));

+		break;

 	}

 	return err ? NOTIFY_BAD : NOTIFY_OK;

 }

--

From: Rafael J. Wysocki <rjw@sisk.pl>
The x86-64 MCE driver should not attempt to destroy/create a suspended

device, unless it corresponds to a nonboot CPU that failed to go online during

a resume.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>

---

 arch/x86/kernel/cpu/mcheck/mce_64.c |    3 +--

 1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c

===================================================================

--- linux-2.6.orig/arch/x86/kernel/cpu/mcheck/mce_64.c

+++ linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c

@@ -862,11 +862,10 @@ mce_cpu_callback(struct notifier_block *
 	switch (action) {

 	case CPU_ONLINE:

-	case CPU_ONLINE_FROZEN:

 		mce_create_device(cpu);

 		break;

 	case CPU_DEAD:

-	case CPU_DEAD_FROZEN:

+	case CPU_UP_CANCELED_FROZEN:

 		mce_remove_device(cpu);

 		break;

 	}
--