Well, I got two responses:

>>  A stack traceback would be more helpful - that PC location is in the
>>bcopy routine.

Why would the kernel lose in bcopy? Hmmmmm.....

The other was:

At 10:19 PM 1/16/98 GMT, Matthias Scheler wrote:
>In article <1.5.4.32.19980116205602.00ddde08@mail.mindspring.com>,
>	"Kevin P. Neal" <kpneal@pobox.com> writes:
>> Am I just hosed?
>
>Try booting into single user mode (skip "-A" when calling "loadbsd")
>and call "fsck -fp" twice.

*ding!* (that would be the sound of a light bulb lighting up)

I wasn't able to boot into single user mode due to the kernel panicing.
Additionally, my SyQuest 105 that I was installing 1.3 on as an emergency
disk didn't have /dev/MAKEDEV run yet, so it wasn't usable. 

Lucky for me my NetBSD 1.0 install floppy still works, even with a 1.3 kernel.

I booted into the 1.0 install floppy and mounted the SyQuest. The boot
floppy MAKEDEV wouldn't work, so I just manually did mknod's on /dev/console
and /dev/*sd3a. (I had to go to great pains to actually _find_ that boot
floppy!)

Then I booted into my emergency disk. I ran MAKEDEV, like I should have done
earlier before the power flicker. Then I fsck'd my damaged partitions.

My root filesystem's superblock was _trashed_. My guess is that it had
values that were so "wack" that the kernel accepted it without checking and
then went off into la-la land when it tried to use those trashed values.
Shouldn't there be better sanity checking of the superblock values?

My /usr was gone, so I reinstalled it from the 1.3 dist. I added back a
couple of symlinks that were in /usr/local, and I'm back up and running now. 

Thanks for the help. 
--
XCOMM Kevin P. Neal, Junior, Comp. Sci.     -   House of Retrocomputing
XCOMM  mailto:kpneal@pobox.com              -   http://www.pobox.com/~kpn/
XCOMM  kpneal@eos.ncsu.edu              Spoken by Keir Finlow-Bates:
XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!"