Date: Mon, 21 Apr 1997 09:37:36 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: peter@spinner.dialix.com (Peter Wemm) Cc: dfr@nlsystems.com, fsmp@freefall.freebsd.org, freebsd-smp@freefall.freebsd.org 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 Message-ID: <199704211637.JAA13674@phaeton.artisoft.com> In-Reply-To: <199704211006.SAA17187@spinner.DIALix.COM> from "Peter Wemm" at Apr 21, 97 06:06:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704211637.JAA13674>