Date: Tue, 13 Jul 2004 23:00:11 +0200 From: "Willem Jan Withagen" <wjw@withagen.nl> To: "John Baldwin" <jhb@FreeBSD.org>, <freebsd-amd64@FreeBSD.org> Subject: Re: Help my SMP is broken??? Message-ID: <02e301c4691c$630f14b0$471b3dd4@digiware.nl> References: <06b401c46591$49a2b600$471b3dd4@digiware.nl> <02b401c468dc$7c59a4c0$471b3dd4@digiware.nl> <200407131557.05961.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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
????
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.
--WjW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?02e301c4691c$630f14b0$471b3dd4>