Date: Wed, 14 Jul 2004 12:54:49 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-amd64@FreeBSD.org Subject: Re: Help my SMP is broken??? Message-ID: <200407141254.49921.jhb@FreeBSD.org> In-Reply-To: <02e301c4691c$630f14b0$471b3dd4@digiware.nl> References: <06b401c46591$49a2b600$471b3dd4@digiware.nl> <200407131557.05961.jhb@FreeBSD.org> <02e301c4691c$630f14b0$471b3dd4@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 13 July 2004 05:00 pm, Willem Jan Withagen wrote:
> ----- Original Message -----
> From: "John Baldwin" <jhb@FreeBSD.org>
>
> > On Tuesday 13 July 2004 09:22 am, Willem Jan Withagen wrote:
> > > > I'm trying to boot my dual opteron box with a recent kernel.
> > > > Without ACPI is boots single processor, with ACPI I get the stuff
> > > > downbelow.
> > > > ACPI APIC Table: <VIAK8 AWRDACPI>
> > > > panic: AP #1 (PHY# 1) failed!
> > > > cpuid = 0;
> > > > Stack backtrace:
> > > > backtrace() at backtrace+0x17
> > > > panic() at panic+0x1d2
> > > > start_all_aps() at start_all_aps+0x187
> > > > cpu_mp_start() at cpu_mp_start+0x199
> > > > mp_start() at mp_start+0x54
> > > > mi_startup() at mi_startup+0xb8
> > > > btext() at btext+0x2c
> > > > Debugger("panic")
> > > > Stopped at Debugger+0x4d: xchgl %ebx,0x27d461
> > >
> > > I'm trying to figure this one out.....
> > > So I added a printf into init_secondary. This is namely the place where
> > > a variable (mp_naps) is incremented to make it out of the waiting loop
> > > in start_all_aps.
> > >
> > > BUT we never get to init_secondary, which I expected to be called from
> > > an interrupt routine. ini_secondary is called from an asm-sequence in
> > > mpboot.S which suggest that it is the first thing to be called once we
> > > get into 64bit mode???
> > >
> > > Is there anywhere a description on how booting is done on UP or SMP
> > > (let alone SMP amd64??)
> >
> > Basically, when a CPU is started up, it starts up in 8086-style real mode
> > executing the code in mpboot.s. That code brings the computer into
> > protected mode and eventually into the same virtual addresses used by the
> > kernel (the mpboot code is dual-mapped to allow for this transition). At
> > that point the AP can safely call into the kernel and it calls
> > init_secondary(). If the AP faults during the early boot code it will
> > basically die and never get into init_secondary(). Also, if the IPI is
> > somehow lost then it will never get into init_secondary().
>
> Some of this I sort figured from comments in mpboot.s
>
> So any suggestions on how to debug this...
> Or could this be broken hardware:
> CPU
> APIC
> Motherboard
> ????
Well, it might be that there's a bug in mpboot.s. :) I'm not familiar with
the amd64 bootstrap though, peter@FreeBSD.org is the most familiar with it.
> I'll try and boot
> - the amd64 version of Windows XP, to see what happens.
> - FreeBSD/amd64 in UP with APCI
> and see what goes??
>
> What exactly is the AP??? and what is an IPI??
> Perhaps stuppid questions, but I'm sort of 10 years out of processors and
> stuff.
AP = Application Processor in Intel lingo. The boot processor is called the
BSP and all other CPUs are called APs.
IPI = Inter-Processor Interrupt. Basically, one CPU sends an interrupt
message to one or more CPUs.
--
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200407141254.49921.jhb>