From owner-freebsd-smp Thu Apr 29 11: 1:48 1999 Delivered-To: freebsd-smp@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 97C4C150AE for ; Thu, 29 Apr 1999 11:01:42 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id OAA17851; Thu, 29 Apr 1999 14:01:05 -0400 (EDT) (envelope-from luoqi) Date: Thu, 29 Apr 1999 14:01:05 -0400 (EDT) From: Luoqi Chen Message-Id: <199904291801.OAA17851@lor.watermarkgroup.com> To: mike@smith.net.au Subject: Re: Really slow SMP Cc: darius@dons.net.au, freebsd-smp@FreeBSD.ORG, peter@netplex.com.au, tlambert@primenet.com 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 > IIRC, disable_intr() for SMP needs to get a lock to prevent intr from occuring on all cpus. In any case, it's safer to do it ap_init() when the AP holds the giant lock. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message