Help my SMP is broken???

[John Baldwin]

On Tuesday 13 July 2004 05:33 pm, Willem Jan Withagen wrote:
> > From: "John Baldwin" <jhb at 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
> >     ????
> >
> > 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.
>
> Well, booting Windows/64 XP seems to be a good "heilmeister" for the
> trouble:
>
> real memory  = 2146304000 (2046 MB)
> Physical memory chunk(s):
> 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages)
> 0x000000000074c000 - 0x000000007c2b7fff, 2075574272 bytes (506732 pages)
> avail memory = 2062815232 (1967 MB)
> ACPI APIC Table: <VIAK8  AWRDACPI>
> SMP: bootAP CPU #1 Trying to launch!
> APIC ID: physical 0, logical 0:0
> APIC ID: physical 1, logical 0:1
> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>  cpu0 (BSP): APIC ID:  0
>  cpu1 (AP): APIC ID:  1
> APIC: CPU 0 has ACPI ID 0
> APIC: CPU 1 has ACPI ID 1
> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000
>
> And now the box just boots fine???
>
> Any suggestions what XP might have fixed???? Can't be that a firmware
> setting is sticky and windows unglued it?!

I have no idea.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org