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>