Date: Fri, 10 Sep 1999 13:00:47 +0000 (GMT) From: Adam Strohl <adams@digitalspark.net> To: Peter Wemm <peter@netplex.com.au> Cc: Luoqi Chen <luoqi@watermarkgroup.com>, iwasaki@jp.FreeBSD.ORG, stable@FreeBSD.ORG, jkh@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: URGENT! HEADS UP: 3.3-RC SMP + APM -> FIX Message-ID: <Pine.BSF.4.10.9909101250470.393-100000@nightfall.digitalspark.net> In-Reply-To: <19990910145217.F0BE61CA8@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmmm, I was thinking (uh-oh): Actually, all you really need to do is get the ability to set a processes' affinity working. When you call something like suspend, etc, move everything off the AP(s) then preform the call. Basically like in BeOS disabling a CPU with the CPU tool. Of course this'd require losts of work, but it'd be work that was already needed. Let me know if that's the stupidest thing you've ever heard, it sounds reasonable to me, but I'm not a kernel developer ;'D - ----( Adam Strohl )------------------------------------------------ - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.net xxx.xxx.xxxx xxxxx - - ----------------------------------------( DigitalSpark.NET )------- - On Fri, 10 Sep 1999, Peter Wemm wrote: > Luoqi Chen wrote: > > Hmm, this change doesn't belong in -stable. I remember I committed it > > to the head of the branch, how does it end up in -stable? It should > > definitely be taken out. > > BTW; to quote Linux's Alan Cox on one thread over SMP vs APM problems > and hacks that partially work under Linux: > "APM will never be SMP safe, the problem is at the BIOS level not Linux" > > I've re-read the mpspec 1.4.6 stuff and I can't find a single mention of > APM in it. > > IMHO, it's a pretty safe assumption that APM should not be called for > anything more than things like ATX poweroff under SMP, and even that's > probably best to defer until after all the AP's have been halted. Things > like suspend, cpuclock slowdown, idle showdown etc are seriously bad for > SMP systems as the cpu calling the bios will be the one affected. (eg: a > suspend-to-disk will put the calling CPU into SMI mode and dump it's state > to disk... the other poor cpu's context is going to be lost, and indeed the > other cpu will continue running *during* the suspend-to-disk...) > > For stuff like this to work, we're going to need to do a lot of sync work > to get the AP's sufficiently quiescent so no damage is done while the APM > code is active, and so that we can reboot the AP's after a suspend-to-disk > recovery. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9909101250470.393-100000>