From owner-freebsd-bugs  Mon Dec  8 17:30:04 1997
Return-Path: <owner-freebsd-bugs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA09255
          for bugs-outgoing; Mon, 8 Dec 1997 17:30:04 -0800 (PST)
          (envelope-from owner-freebsd-bugs)
Received: (from gnats@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id RAA09246;
          Mon, 8 Dec 1997 17:30:01 -0800 (PST)
          (envelope-from gnats)
Date: Mon, 8 Dec 1997 17:30:01 -0800 (PST)
Message-Id: <199712090130.RAA09246@hub.freebsd.org>
To: freebsd-bugs
Cc: 
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Subject: Re: kern/5244: F00F workaround dosn't always work on SMP system. 
Reply-To: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/5244; it has been noted by GNATS.

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.