> On Sat, 26 Feb 2000 11:58:07 +0100, "Eric Delcamp" <e.delcamp_NOSPAM@wanadoo.fr> wrote:
> > Hi !
> > 
> > On my home, same board with dual-Celeron give same result.
> > I drop into db, where 'c' could resume the boot process, and I could dump
> > dmesg.
> 
> Wow.  Never thought of continuing with 'c'.  I'll give it a try.

Currently, if a secondary processor shows no sign of life (i.e., all
the prerequisites are in place, and it's been kicked appropriately,
but doesn't start) and the kernel is build with DDB, it drops into
DDB.  if you continue, you keep going with just the main CPU..
Clearly not appropriate for production systems, but we're nowhere near
that point right now.. :-)

So far, I've seen two or three reports of the secondary processors
failing to start.  As a blindingly obvious test: have you tried a
different MP OS on the system, and did it successfully start the other
processor?

If the system's built with MPDEBUG, you can see how far into
cpu_spinup_trampoline the processor got.. There's a debugging hack in
place in mptramp.s to let you see how far the other CPU's getting into
the startup code (it's way to premature to run the kernel debugger on
that CPU at that point...).

It would useful to see the output from

db> x/xxx cpu_trace

(dumping the three longwords starting at cpu_trace).

(0x40/0xff/0xff is the initial value).

the first word of the three is a "hold point"; the second word gets
set when it passes the hold point, and the third is set to a
"interesting" register value when it hits the hold point; see the
HALT() and HALTT() macros in mptramp.s

If you set the first word to zero before the secondary CPU is started,
and then gradually set it to increasing values, you can observe and
control the forward progress of the secondary CPU from ddb on the boot
processor..

					- Bill