From owner-freebsd-alpha Thu Jul 19 11:59:58 2001 Delivered-To: freebsd-alpha@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 1838D37B405 for ; Thu, 19 Jul 2001 11:59:50 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.3/8.9.3) with ESMTP id f6JIxjF65594; Thu, 19 Jul 2001 11:59:45 -0700 (PDT) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.1) id f6JIxil42122; Thu, 19 Jul 2001 11:59:44 -0700 (PDT) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 19 Jul 2001 11:59:43 -0700 (PDT) From: John Baldwin To: Matthew Jacob Subject: RE: multiple cpus on an 8200... Cc: alpha@FreeBSD.ORG Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 19-Jul-01 Matthew Jacob wrote: > > I got multiple CPUs to appear to be available on an 8200... > > 1. I had to fake past the 'processor available' bit- it wasn't set for the > second CPU even though SRM said it was present and availabele... Yuck. > 2. I came up, and it released it: > > release_aps: releasing secondary CPUs > SMP: AP CPU #9 Launched! > > and I got to a login prompt... but very strangely the system locks up briefly > and then runs okay again. It's quite bizaare. One has to wonder whether or > not > there are some implicit assumptions in the code in places about CPUId. > > It also might in fact be an efficiency issue. We're using PAL calls for > interprocessor interrupts. That *might* be less efficient than using some h/w > specific mechanisms for IPIs. Oh- actually, now that I think about it- I > might > not have enabled IPIs for the CPUs, which means, heh, that IPIs might only be > sampled. Yick... I'll go check... If IPI's are sampled, then that would explain the hang, as the vm system uses rendezvous to invalidate mappings, and in a rendezvous we wait for all CPU's to ack the rendezvous before performing the action and returning. I assume you mean enabling IPI's in a hardware specific sense in SRM or some such? > -matt -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message