Subject: Re: how to recover a lost S(t)unOS disklabel
To: None <port-sparc@NetBSD.ORG>
From: None <r.evans@ic.ac.uk>
List: port-sparc
Date: 08/11/1995 10:00:48
>When I last visited them (quite some time ago), they were still pretty
>experimental, and did not work for my ss1+. pk had them working on
>i forget what sort of box, and mrg use[sd] them on his elc.
I've managed to use them on my SLC (V1.4 prom) for a normal kernel.
However, trying to use them with a kernel built with debugging symbols
fails with "Data Access Exception" (sometimes "Instruction Access
Exception") whilst it's going through the symbol table. Maybe the size
of a kernel with full debug symbols is just too much for it. I haven't
even attempted to look closely at it yet.
Naieve question time...
Whilst I've got fingers to keyboard, should ddb be able to resolve
addresses in a trace if you've booted across the network (and thus
are using a SunOS boot block)? Whenever my machine panics, it drops
down to ddb but typing "trace" doesn't give any useful stack trace.
E.g. after a DMAWAIT1 panic:
ddb> trace
?(f8567b80, 0, 200, 0, f808ed78, f9750a9c) at 0xf808ee94
?(f856dc00, f8090e60, 302b18ab, 78b2f, 1cd7, f00021df) at 0xf80914f4
... and so on
(would a dmawait1 panic be trashing the stack? maybe I'll just have to
force some other panics to see how it handles them!)
Rob