Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Jan 1999 12:01:43 +0000 (GMT)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Wilko Bulte <wilko@yedi.iaf.nl>
Cc:        freebsd-alpha@FreeBSD.ORG
Subject:   Re: porting to EB64+ / Alpine
Message-ID:  <Pine.BSF.4.01.9901101159500.381-100000@herring.nlsystems.com>
In-Reply-To: <199901091955.UAA24119@yedi.iaf.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 9 Jan 1999, Wilko Bulte wrote:

> As Doug Rabson wrote...
> 
> > > sio0: type 16550A
> > > sio1: reserved for low-level i/o
> > > panic: possible stack overflow
> > > 
> > > panic
> > > Stopped at      Debugger..ng+0x24:      ldq     ra,0(sp)
> > > <0xfffffc0000578230>   <ra=0xfffffc00004
> > > 698b8,sp=0xfffffc0000578230>
> > > db> 
> > > 
> > > I have also seen 'panic: clock not attached'. As I'm trying to find my way
> > > around in the kernel source tree I appreciate any hints.
> > 
> > This usually happens if an interrupt is enabled but not handled.  The
> > interrupt exception tries to return but is immediately reentered with a
> > few bytes less stack.
> 
> Interrupts... (I did not have any interrupt mapping setup ;-) I'm trying
> to get an understanding of how that works now.
> 
> Somewhat related question: I would appreciate the output of SHOW CONF
> of a genuine EB64+. My Aspen Alpine is different enough to make this
> interesting.

I imagine that SRM had enabled a few pci interrupts for booting and this
is what was interrupting.  Most of the platform code (e.g.
dec_st550.c) disables all the interrupts that it doesn't know about to
avoid this.

--
Doug Rabson				Mail:  dfr@nlsystems.com
Nonlinear Systems Ltd.			Phone: +44 181 442 9037



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?Pine.BSF.4.01.9901101159500.381-100000>