Date: Mon, 02 Sep 1996 14:32:17 -0600 From: Steve Passe <smp@csn.net> To: Terry Lambert <terry@lambert.org> Cc: freebsd-smp@FreeBSD.ORG, rv@groa.uct.ac.za, erich@uruk.org Subject: Re: SMP on Intel MG15 Message-ID: <199609022032.OAA06728@clem.systemsix.com> In-Reply-To: Your message of "Mon, 02 Sep 1996 13:00:12 PDT." <199609022000.NAA02837@phaeton.artisoft.com>
index | next in thread | previous in thread | raw e-mail
Terry,
I am answering your last 3 mailings in this one...
=========================================================================
#1:
>I don't know if there are pre-1.x versions of the local APIC. That
>could explain the difference.
>
>There is also the possibility that the processors are an old stepping.
Processor
apic ID: 0, version: 16
CPU is usable, CPU is is the bootstrap processor
family: 5, model: 2, stepping: 11
looks reasonable...
>There is also the possibility that this motherboard is simply not
>compliant with the specification. If this is what's going on, then
>the code to handle it should be special cased to make sure that
>people who follow on know that its use is an intentional kludge
>to work around a bug rather than "the way things are done" or a
>result of an imperfect understanding of the specification by the
>FreeBSD coders (another kludge).
once I get it to work I will do this...
=========================================================================
#2:
>Ah. I am quopting a 1.1 specification because the current one up for
>FTP won't print on HP PostScript printers, and being a FreeBSD person,
>I don't have any Adobe code I can run to use the PDF version instead.
>I'm waiting for a hardcopy via snail-mail.
it worked for me by using ghostscript to an HP lj4p
xpdf does a nice job with PDF files for me. beware, when you "print"
files the merely end up in a file named xxx.ps, you need to manually go and
"lpr xxx.ps" the result.
>This is certainly a change, and meshes with what Russell quoted from
>his dmesg output -- the board claims it is a version 1.4 specification
>compliant board.
there was a BIOS option to use version 1.1, which we tried without change.
>I suppose this still leaves the problem of how to tell which of the
>startup methods will work, since you don't want to stomp the warm-reset
>vector if you can avoid it, since the only way to reliably cause a
>PC-class machine to reset is to force it to real mode and cause it to
>jump to the warm reset vector. 8-(.
I solved this problem by saving the current vector and CMOS "reason"
b4 altering it, then restoring them once the 2nd CPU has booted (or
failed to boot).
>Does the B.4.1 specifically state that STARTUP IPI *can't* be use on
>the (735/90, 815/100) processors, or give some other way to tell, from
>software, when it is necessary?
not that I can see. I have used quite a few variations of this theme
to get the XXPRESS working. they ALL work on my box, NONE do the
trick on the XXPRESS!
=========================================================================
#3:
>From my reading of the 1.1 specification, the STARTUP IPI method is
>the preferred method, and the INIT IPI method is deprecated for use
>by systems with external APIC's.
It is my current belief that the INIT/RESET IPI should be used even
with the P5/integrated APIC for purposes of getting it back to
a known real-mode, non-paging state. thus my patch to have it
vector to a HLT instruction. I don't think a "standard BIOS warmstart"
will necessarily affect the 2nd CPU, hence the need to do this.
General algorithm:
if ( 80489DX ) {
set BIOS warmstart vector to 2nd CPU boot code, CMOS reason to "warmstart"
do INIT/RESET /* this resets 2nd CPU (???),
causing jump to BIOS, which does warmstart */
}
else if ( P5/APIC ) {
INTI/RESET it to a "HLT" /* get P5 to real-mode */
set vector to 2nd CPU boot code in APIC register
do STARTUP IPI
}
>I derive this implication from the phrase "is used with systems based
>on version 1.x or higher of the local APIC". It's a pretty clear
>indicator that local APIC's, version 1.x or higher, *must* honor the
>STARTUP IPI.
>
>This leaves me believing that your board is 1.4 but *not* 1.1 compliant.
as I mentioned, above, we set the conformance back to version 1.1 to avoid
this complication. But I don't see anything in 1.4 that would prohibit
the same course of action. perhaps I'm not hereing you correctly?
--
smp@csn.net | FreeBSD
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE
04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX
WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR
tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+
=ds99
-----END PGP PUBLIC KEY BLOCK-----
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609022032.OAA06728>