From owner-freebsd-current  Mon Aug 11 09:57:26 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA15670
          for current-outgoing; Mon, 11 Aug 1997 09:57:26 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA15649
          for <current@FreeBSD.ORG>; Mon, 11 Aug 1997 09:57:17 -0700 (PDT)
Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1])
	by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA15898;
	Mon, 11 Aug 1997 10:57:02 -0600 (MDT)
Message-Id: <199708111657.KAA15898@Ilsa.StevesCafe.com>
X-Mailer: exmh version 2.0gamma 1/27/96
From: Steve Passe <smp@csn.net>
To: Bruce Albrecht <bruce@zuhause.mn.org>
cc: current@FreeBSD.ORG
Subject: Re: Trap 9 When Boot SMP 
In-reply-to: Your message of "Mon, 11 Aug 1997 01:33:21 CDT."
             <199708110633.BAA00276@zuhause.mn.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 11 Aug 1997 10:57:02 -0600
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Hi,

> Steve Passe writes:
>  > Hi,
>  > 
>  > Thomas found a 'fix', although we don't understand WHY the problem exists.
>  > It appears that %es is getting corrupted somewhere during boot.  The
>  > 'solution' was:
>  > 
>  > > The es value IS the culprit.
>  > > 
>  > > Havn't found where it is being mangled, I suspect the
>  > > doreti code.
>  > > 
>  > > I nailed es to ds at the top of smp_idleloop in init_smp.c.
>  > >    asm("pushl %ds; popl %es");
>  > 
>  > ---
>  > anyone have any theories about this one?  This is the only reported system
>  > having this problem, and I have no clues as to why...
> 
> I've been having the same problem since May on an Tyan ATX 1668 system
> (with a 5 week hiatus when my machine was sent back to the vendor for
> repairs, including problems with memory).  At the time, Steve
> suspected that it was hardware, but this hack does allow me to run SMP
> now.  Two things in common is that we both have Matrox accelerators
> and NCR SCSI controllers.  Strangely enough, I did have SMP running
> for about a week in early May, but it stopped working about the time I
> did some hardware changes.

do you recall what those hardware changes were?
I don't see the Matrox being trouble at boot as there is no code specific
to that card at boot time.  The NCR code is a possibility,  what/who's BIOS
are you using for the NCR card?

I'll add this patch to the code as some sort of "#ifdef 0" thing and document
it as rogue hardware.  Not much else to do until we can nail down exactly
what the prblem is caused by.

--
Steve Passe	| powered by 
smp@csn.net	|            Symmetric MultiProcessor FreeBSD