From owner-freebsd-alpha  Wed May 10  5:53:43 2000
Delivered-To: freebsd-alpha@freebsd.org
Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1])
	by hub.freebsd.org (Postfix) with ESMTP id BA14537B65A
	for <freebsd-alpha@FreeBSD.ORG>; Wed, 10 May 2000 05:53:37 -0700 (PDT)
	(envelope-from gallatin@cs.duke.edu)
Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30])
	by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id IAA27009;
	Wed, 10 May 2000 08:53:34 -0400 (EDT)
Received: (from gallatin@localhost)
	by grasshopper.cs.duke.edu (8.9.3/8.9.1) id IAA80341;
	Wed, 10 May 2000 08:53:34 -0400 (EDT)
	(envelope-from gallatin@cs.duke.edu)
From: Andrew Gallatin <gallatin@cs.duke.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 10 May 2000 08:53:34 -0400 (EDT)
To: Brett Bump <bbump@mail.enetis.net>
Cc: freebsd-alpha@FreeBSD.ORG
Subject: Re: 3300/3305 and 5300/5305 Problems
In-Reply-To: <3918CBC5.C9495F35@mail.enetis.net>
References: <Pine.LNX.4.10.10005061257280.19862-100000@server.engec.com.br>
	<39148C07.E97DCEAF@mail.enetis.net>
	<14614.49806.293997.4055@grasshopper.cs.duke.edu>
	<3918CBC5.C9495F35@mail.enetis.net>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14617.22897.113127.677981@grasshopper.cs.duke.edu>
Sender: owner-freebsd-alpha@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


Brett Bump writes:
<..>
 > Ok Andrew, here is what we come up with:
 > 
 > halt code = 2
 > kernel stack not valid halt
 > PC = fffffc000049704c
 > boot failure
 > >>>e ra
 > gpr:          1A( R26) FFFFFC000048F9A8
 > >>>
 > 
 > Gdb tells me:
 > 
 > (gdb) l *0xfffffc000049704c
 > 0xfffffc000049704c is in vm_map_lookup (../../vm/vm_map.c:2470).

<...>

 > (gdb) l *0xfffffc000048f9a8
 > 0xfffffc000048f9a8 is in vm_fault (../../vm/vm_fault.c:206).

<...>

 > Hope this helps.
 > 
 > Brett


Yes.  Sorta.  I think we're getting an memory access fault before
we are ready to get one.  Because of this, we end up taking a fault
from somewhere in the vm_fault() call chain & essentially recursing
(<fault>, trap, vm_fault, vm_map_lookup -> <fault>, trap, vm_fault,
vm_map_lookup -> <fault> <...> ), until we run out of stack space and
the palcode puts an end to it.

Please edit sys/alpha/alpha/trap.c and add 
	goto dopanic;
prior to each call to vm_fault().

This should cause a message to be printed on the console similar to:
    trap entry = 0x2 (memory management fault)
    a0         = 0xfffffe00106aa000
    a1         = 0x1
    a2         = 0x0
    pc         = 0xfffffc00004f2f68
    ra         = 0xfffffc00004f2fec
    curproc    = 0xfffffe00145e5cc0
        pid = 1, comm = swapper

Please transcribe this message, this will give me (and anybody else
who cares to help) a clue about what is actually happening.  I'm
really only interested in the first message you see.

Needless to say, don't expect to use this kernel with all the goto
dopanics for anything -- you'll need to revert trap.c back to its
original form once we get this debugged.

Thanks,

Drew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message