lkml.org 
[lkml]   [2006]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [2.6.17-rc5-mm2] crash when doing second suspend: BUG in arch/i386/kernel/nmi.c:174
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-06-07 02:15    [W:0.076 / U:3.420 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site