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:24, you wrote:
> On Wed, 7 Jun 2006 10:13:49 +1000
>
> Nigel Cunningham <ncunningham@linuxmail.org> wrote:
> > > 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.
>
> It all depends on what we mean by "per-cpu state". If we were to remember
> that "CPU 7 needs 0x1234 in register 44" then that would be wrong. But
> remembering some high-level functional thing like "CPU 7 needs to run the
> NMI watchdog" is fine. The CPU bringup code can work out whether that is
> possible, and how to do it.

Does that imply that there's no danger of cpus being hotplugged in a different
order (so that cpu7 becomes cpu5, for example)?

I guess I'm missing an understanding of why one cpu would need a different
configuration to the rest. If it's related to the cpu number, then it
shouldn't matter if a different cpu gets the number, should it? If it's
related to the node that the cpu is on, perhaps the hotplugging code for the
driver should be checking for the reason ("Am I on the node with the... ?")
rather than the cpu number?

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:33    [W:0.139 / U:0.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site