lkml.org 
[lkml]   [2006]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6.17-rc5-mm2] crash when doing second suspend: BUG in arch/i386/kernel/nmi.c:174
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-07 02:09    [W:1.939 / U:1.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site