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

[Nigel Cunningham <ncunningham@linuxmail.org>]

[-- Attachment #1: Type: text/plain, Size: 3141 bytes --]

Hi.

On Wednesday 07 June 2006 10:42, Don Zickus wrote:
> On Wed, Jun 07, 2006 at 10:05:07AM +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wednesday 07 June 2006 09:55, Don Zickus wrote:
> > > > > So my question is/was what is the proper way to handle processor
> > > > > level subsystems during the suspend/resume path on an SMP system. 
> > > > > I really don't understand the hotplug path nor the suspend/resume
> > > > > path very well.
> > > >
> > > > Make it work properly for CPU hotplug for individual CPU and then in
> > > > suspend you take care of "global" state and the last CPU.
> > >
> > > So the assumption is treat all the cpus the same either all on or all
> > > off, no mixed mode (some cpus on, some cpus off).  I guess I was trying
> > > to hard to work on the per-cpu level.
> >
> > This sounds wrong to me. Shouldn't the the effect of hotunplugging a cpu
> > be to put the driver in a state equivalent to if that cpu simply didn't
> > exist? Unplugging shouldn't assume we're going to subsequently have
> > either a driver suspend, or a replug.
>
> This is my biggest problem or maybe my complete lack of understanding, is
> that I don't know how to determine what state I am in during a hotplug
> event, either a cpu removal or a suspend.  Therefore I feel like I have to
> store some persistant data around _just_ in case this is a suspend event.
> Also at the opposite end, how to separate a cpu insert vs. a cpu resume.
> The different being initialize to a global state vs. initialize to a last
> known state.
>
> I thought it would make more sense if a few more states were to the
> hotplug event list.  For example, in addition to CPU_ONLINE and CPU_DEAD,
> there could also be something like CPU_SUSPEND, CPU_FREEZE, CPU_RESUME,
> and CPU_THAW.
>
> Anyway, I am probably complicating the matter.  I'll whip something up and
> post it for review.

Act like...

Unplug: It's going away, never to return.
Plug: It's just appeared from nowhere, is completely uninitialised and may be 
a different item to anything that happened to look the same before.
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.
Resume: You want to restore the state you saved in memory when given the 
suspend call earlier.

Regarding _FREEZE, there is work in progress to add this. I haven't been 
following the conversation really closely recently, but my understanding is 
that you should expect it to be similar to suspend, except that you can 
guarantee that power will not be lost. All activity should be stopped so that 
you get a consistent state which you can restore in the resume call. Every 
suspend or freeze must be followed by a resume.

I'll add the linux-pm list to the cc, just in case I've gotten something wrong 
or the other guys want to comment and have missed this thread.

Hope this helps.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]