Date: Mon, 8 Dec 1997 14:00:02 -0800 (PST) From: Steve Passe <smp@csn.net> To: freebsd-bugs Subject: Re: kern/5244: F00F workaround dosn't always work on SMP system. Message-ID: <199712082200.OAA17959@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/5244; it has been noted by GNATS.
From: Steve Passe <smp@csn.net>
To: freebsd-gnats-submit@FreeBSD.ORG
Cc: mgove@cais.com, smp@FreeBSD.ORG
Subject: Re: kern/5244: F00F workaround dosn't always work on SMP system.
Date: Mon, 08 Dec 1997 14:53:21 -0700
Hi,
> >Number: 5244
> >Category: kern
> >Synopsis: F00F workaround dosn't always work on SMP system.
> > ...
> >Description:
> Intel F00F workaround appears to only install on the first CPU in a dual CPU configuration.
>
> >How-To-Repeat:
> Execute the 'F00F' code, repeatedly. Sometimes it dies with Illegal instruction, sometimes the system hangs.
>
The basic problem is the fact that r_idt is local in UP, and global in SMP.
This is because SMP:init_secondary() uses the global r_idt to sync the
additional CPUs to the boot CPU:
---
machdep.c:
...
#ifdef SMP
/* table descriptors - used to load tables by microp */
struct region_descriptor r_gdt, r_idt;
#endif
...
init386(first)
int first;
{
...
#ifndef SMP
/* table descriptors - used to load tables by microp */
struct region_descriptor r_gdt, r_idt;
#endif
---
mp_machdep.c:
init_secondary(void)
{
...
lidt(&r_idt);
lldt(_default_ldt);
---
I think to trick is to rework f00f_hack() to use the global in the SMP case,
AND to insure that init_secondary() runs AFTER f00f_hack().
I'm not clear on what f00f_hack() does, and do not have the available
hardware to test it (ie dual P5), so I'll have to leave this to someone
else to deal with...
--
Steve Passe | powered by
smp@csn.net | Symmetric MultiProcessor FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712082200.OAA17959>