Date: Wed, 10 May 2000 18:47:22 -0600 From: Brett Bump <bbump@mail.enetis.net> To: freebsd-alpha@FreeBSD.ORG Subject: Re: 3300/3305 and 5300/5305 Problems Message-ID: <391A031A.4CB8509A@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> <14617.22897.113127.677981@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrew Gallatin wrote:
>
> 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().
Ok Andrew here is the next installment in the SAGA of the 3300/3305:
fatal kernel trap:
trap entry = 0x2 (memory management fault)
a0 = 0x0
a1 = 0x1
a2 = 0xffffffffffffffff
pc = 0x0
ra = 0xfffffc00004b16cc
curproc = 0
panic: trap
Uptime: 0s
(gdb) l *0xfffffc00004b16cc
0xfffffc00004b16cc is in alpha_init (../../alpha/alpha/machdep.c:747).
742 cputype = hwrpb->rpb_type;
743 if (cputype >= ncpuinit) {
744 platform_not_supported(cputype);
745 /* NOTREACHED */
746 }
747 cpuinit[cputype].init(cputype);
748 snprintf(cpu_model, sizeof(cpu_model), "%s",
platform.model);
749
750 /*
751 * Initalize the real console, so the the bootstrap
console is
(gdb)
Um...does this look like what I think it looks like?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?391A031A.4CB8509A>