From owner-freebsd-smp Wed Sep 11 23:48:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA15528 for smp-outgoing; Wed, 11 Sep 1996 23:48:14 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA15519 for ; Wed, 11 Sep 1996 23:48:03 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id OAA02113; Thu, 12 Sep 1996 14:40:42 +0800 (WST) Message-Id: <199609120640.OAA02113@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Steve Passe cc: rv@groa.uct.ac.za (Russell Vincent), freebsd-smp@freebsd.org Subject: Re: Intel XXpress - some SMP benchmarks In-reply-to: Your message of "Wed, 11 Sep 1996 14:54:05 CST." <199609112054.OAA11976@clem.systemsix.com> Date: Thu, 12 Sep 1996 14:40:41 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > I have submitted formal bug reports via send-pr for the following 4 issues: > [Applied, thanks] > Subject: SMP kernel fix 960909.4 > --- > It has the internal identification `kern/1594'. > >Category: kern > >Responsible: freebsd-bugs > >Synopsis: apic_startup() needs work Hmm, something seems to have gone wrong, my second CPU isn't found with this patch present, so I'll see if I can see what went wrong.. [..] > feel they should be submitted to send-pr. The correct solution will > require some sort of 'physical' to 'virtual' mapping table for IDs. > > The basis of the problem is that the kernel expects the BSP to have ID #0 > and the AP to have ID #1. The Intel XXPRESS numbers it's CPUs 0 (BSP), > 2, 3 and 4. These band-aids merely shift 2,3,4 to 1,2,3. I have a better solution in mind. :-) Hint: ALL the APIC ID registers are read/write. Can you see it yet? :-) Apart from the existance of the XXPRESS board, the nice easy solution is to have the boot cpu assign it's ID to zero, and send a broadcast STARTUP IPI and have the application cpu's fight for a lock, and assign themselves sequentially increasing ID's, and assign the IO apic's ID to the end of the list. One thing I'm not clear about from the IO apic docs yet is whether there are 15 cpu's and 15 IO apic's, or whether there's a limit of 15 devices on the APIC bus. BTW, those .pdf docs you pointed out have done the trick and describe the IO apic (version 0x11 at least :-) completely, although it is scattered around different doc files a bit.. As I understand it, the 82371SB PIIX3 chip has an IO apic address decoder, but no apic. The IOAPIC chip (82093AA) is an optional extra part of the 430HX suite and would only be present on the multi-processor boards. I'm not sure where the 82378ZB SIO and 82379AB SIO.A fit into this picture, but it looks to me like they are a standalone version of the "complete motherboard chipset". All the information is there... The IO apic has only two memory mapped registers, one address, one data. The internal registers, selected and accessed through the visible pair, look (strangely enough) very much like the registers in the local apic..... They could be very easily missed or mistaken for local apic docs. The IO redirection table entries (what we're looking for) are the same layout as the Local APIC's ICR, and very similar to the 3 local vector table entries for LINT0, LINT1 and ERROR. Probably no accident at all.. > You also need to set the BIOS to use cache 'write-thru' as oppossed to > cache 'write-back' to make the XXPRESS happy. Incidently, in one of the books that I did find when I was looking some time ago, it mentions that with the MESI caches in action, write-through was "for speed" (to avoid cache conflict resolution cycles or something) versus write-back and may be required for correct multiprocessor operation.. I'm not sure I trust the book on that, as it's only got a very slim section on the apic and multiprocessing (no detail at all) and is quite cryptic and (I think) self contradicting in places. Naturally I cannot find the reference, so I'm denying this comment exists. :-) Cheers, -Peter