Skip site navigation (1)Skip section navigation (2)
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> 

next in thread | previous in thread | raw e-mail | index | archive | help
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?199712082153.OAA12205>