Date: Mon, 08 Dec 1997 14:53:21 -0700 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. Message-ID: <199712082153.OAA12205@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Sat, 06 Dec 1997 19:50:07 PST." <199712070350.TAA11511@hub.freebsd.org>
index | next in thread | previous in thread | raw e-mail
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
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712082153.OAA12205>