It looks like Alpha turns on all the CPUs to start with where x86 only turns on the BP and brings up the APs with IPIs. I think SPARC is actually more similar, but it looks like I'm already doing what it's doing. I remember Ali fixed some of the SPARC SMP boot issues recently, but I looking at that it doesn't seem to address this sort of thing.
Gabe Steve Reinhardt wrote: > Recalling from some of the issues with getting O3 MT to work, I > believe there's a general confusion and inconsistency with respect to > the meanings of "suspended", "unallocated", and perhaps other states. > It's possible (maybe even likely) that the code that does SE-mode MT > apps like SPLASH has requirements that are inconsistent with FS mode. > So there's no "right answer" short of figuring out how it ought to be > and fixing the half of the code that assumes something different. > > Can you tell how it works in Alpha FS? Seems like x86 shouldn't be > any different. > > Steve > > On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black <[email protected]> wrote: > >> I'm trying to bring up SMP under x86 FS, and I'm not able to wake up >> any AP because the wakeup function gives up if the CPU isn't suspended. >> The CPUs I'm working with are actually unallocated, so nothing happens. >> I had startupCPU set up to suspend the APs as the came up, but that >> causes a problem with the simple CPUs which insist the thread is >> Running, and again it's Unallocated. How is this supposed to work? Do I >> have to activate and then suspend a context? Or did somebody just leave >> a possible option out of an assert someplace? >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
