From owner-freebsd-smp Thu Apr 29 10:42:32 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dingo.cdrom.com (castles545.castles.com [208.214.165.109]) by hub.freebsd.org (Postfix) with ESMTP id 6352115042 for ; Thu, 29 Apr 1999 10:42:19 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id KAA03121; Thu, 29 Apr 1999 10:41:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199904291741.KAA03121@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Luoqi Chen Cc: darius@dons.net.au, mike@smith.net.au, freebsd-smp@FreeBSD.ORG, peter@netplex.com.au, tlambert@primenet.com Subject: Re: Really slow SMP In-reply-to: Your message of "Thu, 29 Apr 1999 13:35:16 EDT." <199904291735.NAA17634@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 Apr 1999 10:41:01 -0700 From: Mike Smith Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Maybe init_secondary() is too ealier for calling mem_range_AP_init, > APs shouldn't be fooling around with locks at that point. I guess > what happened was the AP was in a spin loop waiting for a lock and > BSP timed out waiting for AP's up signal. Try move the call to ap_init() > instead. Sorry, not sure I follow you here; there's no locking in mem_range_AP_init(), and it's where the MTRRs were being loaded before. The code path is a little more convoluted now, but has the same basic effect. Regardless, Daniel, does that work for you? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message