Date: Mon, 4 Oct 1999 22:58:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luoqi@watermarkgroup.com (Luoqi Chen) Cc: Tor.Egge@fast.no, woju@bbs.ee.ntu.edu.tw, freebsd-smp@FreeBSD.ORG Subject: Re: SMP on 4 Pentium III(450NX) failed Message-ID: <199910042258.PAA19179@usr05.primenet.com> In-Reply-To: <199910041814.OAA04534@lor.watermarkgroup.com> from "Luoqi Chen" at Oct 4, 99 02:14:58 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Does anybody have successful experience for running FreeBSD 3.X-STABLE > > > SMP on 4 Pentium III 550 with Intel 450NX chipset? > > > > > > When I run FreeBSD 3.3-STABLE SMP on AcerAltos 21000, Pentium III 550 x 4, > > > the booting process halt at "Lauching CPU #1". > > > > > > With 4 CPU installed, it halted at "SMP: AP CPU #3(or #2) Launched!". > > > > [....] > > > > > INT active-hi level 0 7:D 2 19 > > ^^^^^^^^^ ^^^^^^ > > > > > INT active-lo level 0 11:A 2 19 > > ^^^^^^^^^ ^^^^^^ > > Same pin, opposite polarity. > > This might cause an infinite interrupt loop. > > > > > INT active-lo level 1 9:A 2 23 > > > INT active-lo level 1 9:B 2 23 > > > > The MP table seems broken. You'll probably have to edit mptable_pass1 > > and mptable_pass2 to ignore the entry for pci0.7 (the active-hi level > > one). > > > > - Tor Egge > > I'm wondering how NT handles this case? Most likely by either keeping it's own table of the pins that it fills in based on the pin number (which would result in the second entry overwriting the first, which is probably correct behaviour, since it would allow a soft patch of a ROM bug via a BIOS update), by ignoring "active-hi" pins entirely, or by prioritizing which entry to believe (via "7:D"/"11:A" comparison). It would be interesting to set up an email alias at FreeBSD.org, and attach a script to it that knows how to characterize the "brokenness" of "broken" MP tables, and then have everyone with a "broken" MP table send it to the alias to better characterize the classes of "broken" so that the software could resolve the problem itself, without needing a list of "known rogues" or user kernel modification/(re)configuration. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910042258.PAA19179>