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>