From owner-freebsd-smp Mon Sep 2 13:33:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11102 for smp-outgoing; Mon, 2 Sep 1996 13:33:49 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA11094 for ; Mon, 2 Sep 1996 13:33:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA06728; Mon, 2 Sep 1996 14:32:17 -0600 Message-Id: <199609022032.OAA06728@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terry Lambert cc: freebsd-smp@FreeBSD.ORG, rv@groa.uct.ac.za, erich@uruk.org Subject: Re: SMP on Intel MG15 In-reply-to: Your message of "Mon, 02 Sep 1996 13:00:12 PDT." <199609022000.NAA02837@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Sep 1996 14:32:17 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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-----