Date: Mon, 29 Oct 2001 13:27:15 -0800 From: Marcel Moolenaar <marcel@cup.hp.com> To: Doug Rabson <dfr@nlsystems.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ia64/ia64 interrupt.c mp_machdep.c Message-ID: <20011029132715.A38320@gauss.cup.hp.com> In-Reply-To: <Pine.BSF.4.33.0110292107100.62940-100000@herring.nlsystems.com> References: <20011029101414.A37597@gauss.cup.hp.com> <Pine.BSF.4.33.0110292107100.62940-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 29, 2001 at 09:09:35PM +0000, Doug Rabson wrote: > On Mon, 29 Oct 2001, Marcel Moolenaar wrote: > > > On Mon, Oct 29, 2001 at 09:33:27AM +0000, Doug Rabson wrote: > > > On Sun, 28 Oct 2001, Marcel Moolenaar wrote: > > > > > > > marcel 2001/10/28 23:34:48 PST > > > > > > > > Modified files: > > > > sys/ia64/ia64 interrupt.c mp_machdep.c > > > > Log: > > > > o Send a test IPI from the BSP to itself at the same time APs > > > > are woken up. > > > > o Make IPIs synchronuous by default. If we want asynchronuous > > > > IPIs, we may want to make the memory fence controllable. > > > > > > Hmm. Looks like you are dangerously close to starting those other cpus... > > > > It looks like APs are woken up, because the test IPI is delivered. > > I just need to have the OS_BOOT_RENDEZ do sufficient initializations. > > I don't think I have any DTR enties because I couldn't see any data > > on the screen when writing to the frame-buffer as a way to see if > > the AP actually woke up. > > You need to setup ITR and DTR to map the first 256Mb of memory. Also as > soon as possible you need to call map_pal_code() to pin down the region > which holds the PAL (preferably *before* you try calling any PAL > functions. I didn't know about map_pal_code(). Thanks! > > BTW: I moved scanning the MADT to a place where it now happens to > > be called only when SMP is defined. This is bogus. I probably > > broke non SMP configs :-/ > > I guess it needs its own SYSINIT to make it run just before the MP > initialisation code. I'll take a look at it this evening. I hope we can avoid it... What I really like is fix the MBUF code. It's the only user of 'all_cpus' and has a fixed upper bound on the number of CPUs (NCPU), whereas MD code uses MAXCPU. We currently don't need MAXCPU on ia64 and hope we can get rid of NCPU in MI code as well. It's probably not going to happen soon, though :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011029132715.A38320>