From owner-freebsd-smp  Mon Apr 21 09:39:56 1997
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id JAA28765
          for smp-outgoing; Mon, 21 Apr 1997 09:39:56 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA28752;
          Mon, 21 Apr 1997 09:39:46 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id JAA13674; Mon, 21 Apr 1997 09:37:36 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199704211637.JAA13674@phaeton.artisoft.com>
Subject: Re: cvs commit: sys/i386/i386 mp_machdep.c sys/i386/include smptests.h sys/i386/conf options.i386 sys/i386/isa clock.c isa.c
To: peter@spinner.dialix.com (Peter Wemm)
Date: Mon, 21 Apr 1997 09:37:36 -0700 (MST)
Cc: dfr@nlsystems.com, fsmp@freefall.freebsd.org,
        freebsd-smp@freefall.freebsd.org
In-Reply-To: <199704211006.SAA17187@spinner.DIALix.COM> from "Peter Wemm" at Apr 21, 97 06:06:03 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > >   Modified:    i386/conf  options.i386
> > >   Log:
> > >   added option  SMP_TIMER_NC
> > >   this option informs the kernel that the motherboard MP table incorrectly
> > >   states that the 8254 timer is connected to the IO APIC.
> > >   it replaces the #define in smptests.h: FAKE_8254_NC
> > 
> > That did it!  I added SMP_TIMER_NC to my config and I am now up and
> > running with the SuperMicro P6DNE machine.
> 
> Hmm..  I wonder how the hell we can detect this sort of problem at 
> runtime?  Having to twiddle half a dozen compile-time options to get a 
> system booted isn't my idea of a good outcome..
> 
> I think the "best" answer is to decouple the idt slots and spl* bit 
> patterns, then we can do things like spreading the idt load and have 
> "lots" of interrupt sources... (eg: multiple apics)

The timer would be causing non-APIC int's, right?

One way might be to count int's, and if the timer has not changed
over some N count, then assume it's incorrectly identified.  This
should be front-loaded, so the timer check doesn't occur all the
time.


Alternately, request a patch for the MPtable from the vendor,
since this is a known problem?

Or ask them how NT copes?


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.