Help my SMP is broken???
jhb at FreeBSD.org
Wed Jul 14 11:58:23 PDT 2004
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
> > > > 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
> > > 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
> Well, booting Windows/64 XP seems to be a good "heilmeister" for the
> 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
More information about the freebsd-amd64