From owner-freebsd-smp  Mon Jul 21 19:01:12 1997
Return-Path: <owner-freebsd-smp>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id TAA27147
          for smp-outgoing; Mon, 21 Jul 1997 19:01:12 -0700 (PDT)
Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27136
          for <freebsd-smp@FreeBSD.ORG>; Mon, 21 Jul 1997 19:01:05 -0700 (PDT)
Received: (qmail 15010 invoked by uid 1000); 22 Jul 1997 02:01:18 -0000
Message-ID: <XFMail.970721190118.Shimon@i-Connect.Net>
X-Mailer: XFMail 1.1 [p0] on FreeBSD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199707212203.QAA07227@Ilsa.StevesCafe.com>
Date: Mon, 21 Jul 1997 15:21:22 -0700 (PDT)
Organization: Atlas Telecom
From: Simon Shapiro <Shimon@i-connect.net>
To: Steve Passe <smp@csn.net>
Subject: Re: P6DNH Question
Cc: freebsd-smp@FreeBSD.ORG
Sender: owner-freebsd-smp@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk


Hi Steve Passe;  On 21-Jul-97 you wrote: 
> Hi,
> 
> > > in your smptests.h file:
> > >  comment out:
> > >   NEW_STRATEGY
> > >   APIC_PIN0_TIMER
> > >   TEST_ALTTIMER
> > >   TIMER_ALL
> > > 
> > > then go to the i386/conf dir and restore the "options SMP_TIMER_NC".
> > > run config, go to the build dir, make depend && make && make install.
> > > let me know if this works (or not).
> > 
> > Not :-(
> > 
> > Same symptoms;  stuck in default_halt just before execing init.  
> 
> I'm going to need detailed info to be able to be of help.  The ideal
> situation is to setup your box to use a serial console, and use an
> xterm on another machine to connect to the target box.  Then you can
> capture
> the complete output thru the point of failure.  See the freebsd handbook
> for details. 

I already posted all the details (OK, minus some prompts).  There is
nothing much to tell;  Boot proceeds totally normally until the point at
which /etc/rc starts (on a UP).  At this point nothing happens.  At all.
If I ctl-alt-esc into the debugger, I am told the processor is in
default_halt + 0x01.  If I tell the debugger to continue, it actually tries
to call boot().  Boot gets confused because I have a function registered
with at_shutdown which tsleep()s.  This last part has nothing to do with
SMP as this confusion exists in the UP kernel as well.

I will be very happy to supply whatever information is necessary, including
access to the errant machine.  BTW, the handbook is out of date on serial
console, last I checked.  I wanted to add that for a long time...

Simon