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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux