Date: Fri, 10 Sep 1999 22:52:17 +0800 From: Peter Wemm <peter@netplex.com.au> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: 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: <19990910145217.F0BE61CA8@overcee.netplex.com.au> In-Reply-To: Your message of "Fri, 10 Sep 1999 09:54:29 -0400." <199909101354.JAA12917@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> -lq
>
> > Hi,
> >
> > If you have problems on 3.3-RC SMP system with APM enabled,
> > please test the attached patch and give feedback to me ASAP.
> >
> > The problem I was reported is that a lot of userland programs get
> > signal 11 and core dumped on startup. It seems my bad MCF (8/24)
> > breaks extra GDT entries for SMP.
> >
> > The following patch was already tested among folks in Japan, I
> > want fix this before 3.3-RELEASE.
> >
> > <To Release Coordinator>
> > My I commit this for RELENG_3 if somebody reports `fixed!' ?
> > </To Release Coordinator>
> >
> > Index: i386/apm/apm.c
> > ===================================================================
> > RCS file: /home/ncvs/src/sys/i386/apm/apm.c,v
> > retrieving revision 1.77.2.6
> > diff -u -r1.77.2.6 apm.c
> > --- apm.c 1999/08/29 16:04:32 1.77.2.6
> > +++ apm.c 1999/09/10 11:57:40
> > @@ -20,7 +20,6 @@
> >
> > #include "opt_devfs.h"
> > #include "opt_vm86.h"
> > -#include "opt_smp.h"
> >
> > #include <sys/param.h>
> > #include <sys/systm.h>
> > @@ -53,10 +52,6 @@
> > #include <machine/vm86.h>
> > #endif
> >
> > -#ifdef SMP
> > -#include <machine/smp.h>
> > -#endif
> > -
> > static int apm_display __P((int newstate));
> > static int apm_int __P((u_long *eax, u_long *ebx, u_long *ecx, u_long *edx
));
> > static void apm_resume __P((void));
> > @@ -127,10 +122,6 @@
> > static void
> > setup_apm_gdt(u_int code32_base, u_int code16_base, u_int data_base, u_int
code32_limit, u_int code16_limit, u_int data_limit)
> > {
> > -#ifdef SMP
> > - int x;
> > -#endif
> > -
> > /* setup 32bit code segment */
> > gdt_segs[GAPMCODE32_SEL].ssd_base = code32_base;
> > gdt_segs[GAPMCODE32_SEL].ssd_limit = code32_limit;
> > @@ -147,14 +138,6 @@
> > ssdtosd(gdt_segs + GAPMCODE32_SEL, &gdt[GAPMCODE32_SEL].sd);
> > ssdtosd(gdt_segs + GAPMCODE16_SEL, &gdt[GAPMCODE16_SEL].sd);
> > ssdtosd(gdt_segs + GAPMDATA_SEL , &gdt[GAPMDATA_SEL ].sd);
> > -
> > -#ifdef SMP
> > - for (x = 1; x < NCPU; x++) {
> > - gdt[x * NGDT + GAPMCODE32_SEL].sd = gdt[GAPMCODE32_SEL].sd;
> > - gdt[x * NGDT + GAPMCODE16_SEL].sd = gdt[GAPMCODE16_SEL].sd;
> > - gdt[x * NGDT + GAPMDATA_SEL ].sd = gdt[GAPMDATA_SEL ].sd;
> > - }
> > -#endif
> > }
> >
> > /* 48bit far pointer. Do not staticize - used from apm_setup.s */
> >
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-smp" in the body of the message
>
>
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990910145217.F0BE61CA8>