From nobody  Sat Dec  6 19:50:07 1997
Received: (from nobody@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA11511;
          Sat, 6 Dec 1997 19:50:07 -0800 (PST)
          (envelope-from nobody)
Message-Id: <199712070350.TAA11511@hub.freebsd.org>
Date: Sat, 6 Dec 1997 19:50:07 -0800 (PST)
From: mgove@cais.com
To: freebsd-gnats-submit@freebsd.org
Subject: F00F workaround dosn't always work on SMP system.
X-Send-Pr-Version: www-1.0

>Number:         5244
>Category:       kern
>Synopsis:       F00F workaround dosn't always work on SMP system.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec  6 20:00:06 PST 1997
>Closed-Date:    Sat Jul 21 22:48:15 PDT 2001
>Last-Modified:  Sat Jul 21 22:48:52 PDT 2001
>Originator:     Matthew E. Gove
>Release:        3.0-CURRENT
>Organization:
>Environment:
FreeBSD monolith.mgove.org 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Fri Dec  5 20:55:21 EST 1997     root@monolith.mgove.org:/usr/src/sys/compile/MONOLITH  i386

>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.

>Fix:

>Release-Note:
>Audit-Trail:

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
 
 

From: Stephen McKay <syssgm@dtir.qld.gov.au>
To: Steve Passe <smp@csn.net>
Cc: freebsd-gnats-submit@freebsd.org, syssgm@dtir.qld.gov.au
Subject: Re: kern/5244: F00F workaround dosn't always work on SMP system. 
Date: Tue, 09 Dec 1997 11:24:53 +1000

 On Monday, 8th December 1997, Steve Passe wrote:
 
 > > Intel F00F workaround appears to only install on the first CPU in a
 > > dual CPU configuration.
 
 > 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:
 
 Ooh that's tacky!  And the current F00F workaround makes it a little worse
 by adding t_idt.  I think we should have 'struct gate_descriptor *idt' and
 point that at 'normal_idt' or 'f00f_idt' as necessary.  Plus mp_machdep.c
 should build its own 'struct region_descriptor' and only refer to 'idt'.
 Thus only 'idt' need be global.  Hmm, or simply create a loadidt() in
 machdep.c that does the right thing.
 
 As a bonus for this 'idt' tidying, setidt() would work again after f00f_hack()
 runs.
 
 Stephen.

From: Tim Vanderhoek <vanderh@ecf.utoronto.ca>
To: freebsd-gnats-submit@FreeBSD.ORG
Cc:  
Subject: Re: kern/5244
Date: Mon, 21 Jun 1999 10:29:41 -0400

 [forwarded to gnats]
 
 Subject-was: Re: cvs commit: src/sys/i386/i386 locore.s machdep.c trap.c src/sys/i386/include segments.h
 
 On Sat, Jun 19, 1999 at 03:43:52PM -0400, Bruce Evans wrote:
 > >>   Log:
 > >>   Changed the global `idt' from an array to a pointer so that npx.c
 > >>   automatically hacks on the active copy of the IDT if f00f_hack()
 > >
 > >Does this close kern/5244?
 > 
 > Perhaps accidentally.  I didn't know about PR5244.  I think the previous
 > change of moving f00f_hack() early accidentally ensures that f00f_hack()
 > is run before init_secondary().  This leaves the evil global/local r_idt,
 > which can probably be fixed simply by removing the local definitions
 > of it.
 > 
 > Bruce
 
 -- 
 This is my .signature which gets appended to the end of my messages.
 
State-Changed-From-To: open->closed 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 22:48:15 PDT 2001 
State-Changed-Why:  

This was apparently fixed some time ago.  See the Audit-Trail for 
details. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=5244 
>Unformatted:
