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: 1723 bytes --]

Hi.

On Wednesday 07 June 2006 10:06, Jeremy Fitzhardinge wrote:
> 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

It's probably safter to say "In the suspend/resume case, they may well be." 
It's not inconceivable that a system could be suspended, a faulty cpu 
replaced with another, and the system resumed. Hotplugging ought to handle 
that nicely.

> 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?)

Indeed. I'm also not sure that there's necessarily a guarantee that cpus will 
be hotplugged in the same order. Perhaps those with more knowledge can 
clarify there.

Regards,

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

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