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

[Jeremy Fitzhardinge <jeremy@goop.org>]

Nigel Cunningham wrote:
> * Driver suspend and resume calls should only handle cpu0, and should not 
> touch other processors. The same semantics regarding hardware state and 
> values of variables apply here.
>   
Isn't the trouble that in this case, the devices themselves are the 
CPUs, and so the CPUs themselves need to operate on their own state?

Or perhaps, to look at it another way, suspend/resume is just a special 
case of:

   1. unplug cpus 1-N
   2. [something]
   3. re-plug cpus 1-N

where [something] in this case is "suspend cpu0". 

But the problem is that there's nothing which keeps track of whether the 
re-plugged cpus 1-N are the "same" as the unplugged 1-N, and so nothing 
can apply the same per-cpu settings to them.  In the suspend/resume case 
they clearly are, but in the general remove/add case, do you really want 
the new CPU to get the same state as the old one just because it ends up 
with the same logical CPU number?  Perhaps, but what if it doesn't even 
have the same capabilities?  (Do we support heterogeneous CPUs anyway?)

    J