Re: [linux-pm] [2.6.17-rc5-mm2] crash when doing second suspend: BUG in arch/i386/kernel/nmi.c:174

[David Brownell <david-b@pacbell.net>]

On Tuesday 06 June 2006 5:50 pm, Nigel Cunningham wrote:

> Suspend: It's going to be put into a low (possibly no-) power state. It's 
> going to come back, and when it does, you want to be able to put it back in 
> the state it's in prior to this call.

Not exactly.  Suspended devices can in general can resume() into a RESET
state in which case software reinit is appropriate ... or they can come back
in the state that the suspend() left them in, modulo changes that may come
from hot-unplugging hardware connected to that device.  (Which may be a
wakeup event, depending on system configuration.)

CPU suspend might have additional rules (just like for any pm-smart class
of drivers), but those are the generic rules.  Not that I think many
platforms treat CPUs quite the same as other hardware!  :)

I don't think the PM events -- suspend()/resume() -- should ever be
entangled with hotplug events.  The former apply to devices which are
known; the latter are how they become known (or get forgotten).


> Every suspend or freeze must be followed by a resume.

Freeze is an optional nuance; it's basically OK to treat every suspend() as
an "enter low power mode" suspend request, regardless of the event signified
by its parameter.  The canonical/main example of when it might _not_ do that
is avoiding disk drive spindown on freeze durin swsusp.

It's a bit problematic just now to handle hot-unplug during suspend(), so
the best advice just now is to make sure that if that's physically possible
(like ejecting a PCMCIA/Cardbus adapter) then driver resume() checks whether
the device is present, just like it checks for power-lost/reset.

- Dave