(Note: This report was originally sent to port-mac68K@netbsd.org since I
couldn't locate this address right away. Contents are unchanged from that
send, aside from this note)

The Hardware:
PowerBook 170, 8 megs physical RAM, 256 Meg SCSI drive, Partitioned as 32
megs Mac, 32 megs NetBSD swap, and the remaining
hundred-and-ninety-something megs NetBSD root/usr.

The Software:
NetBSD 1.6BETA1. A fresh install of everything - base, comp, etc, games,
kern-GENERIC, man, misc, and text (all with .tgz extensions) - pulled from
the
ftp://releng.netbsd.org//pub/NetBSD-daily/200205280000/mac68k/binary/sets/
directory. Installed onto a freshly mkfs-ed partition, using (to my
knowledge, the latest available) Installer v1.1h to read from an AppleShare
mounted volume on another machine on the LAN, and booted with Booter
v2.0.0a7 set to the same values that allowed me (before I wiped it out with
mkfs to install the beta) to boot into NetBSD 1.4.3 with no glaringly
obvious trouble.

The problem:
System boots, then when attempting to mount the filesystem so I can use vi
to tinker with the rc.conf file (using '/sbin/mount -u -w /' as specified
in the INSTALL.txt file) I run into trouble.

How it happens:
A "screen dump" with commentary is probably easiest and least verbose...
(I put it in quotes because it's actually a screen transcription, and
therefore subject to my typos and or spelling/capitalization errors. I'm
*PRETTY SURE* I got everything right, though...)

Begin "screen dump":
/etc/rc.conf is not configured.  Multiuser boot aborted.
Enter pathname of shell or RETURN for SH: <RETURN>
Terminal type is vt220
We recommend creating a non-root account and using su(1) for root access.
# /sbin/mount -uKernel FPU trap.
trap type 16, code = 0x0, v=0x0
kernel program counter = 0x194
kernel: type 16 trap
pid = -1 pc = 00000194, ps = 2108 sfc = 1 dfc = 1
Registers:
             0        1        2        3        4        5        6        7
dreg: FFFFFFFF FFFFFFFF 00296E70 00002100 00000010 00000004 00000004 0020F6A4
areg: 002233BC 00000010 001EE0A8 001EE08C 00224880 0019DA40 40120000 FFFFCFFC

Kernel stack (00296DC8):
296DC8: 001A34A4 00296E18 00000080 00296E70 00002100 00000010 00000004 00000004
<skipping 14 more lines worth of stack-dump to save space/potential errors>
296FA8: 0062DEEC 00626336 00000FF0 000A4B5A 0029A000 00000000 00001000
00001000
panic: trap
Stopped at     cpu_Debugger+0x6:   unlk    a6
db>

End "screen dump", begin commentary.

Note about the stack dump:
If you think the whole thing will be useful, great, let me know and I'll
transcribe it. Otherwise, I suspect it's nothing but wasted time/bandwidth,
and a potential source of misinformation due to errors that I'm likely to
make trying to transcribe so many hex values. FWIW: Comparing the part I
did include to multiple re-creations of the crash shows that the first and
last lines of the stack dumps are identical every time. Perhaps this is a
significant fact? Or just wishful thinking on my part? Further FWIW: The
dreg/areg values are also identical in each case.

All looks good through the boot. All values appear sane, and essentially
indistinguishable from a good 1.4.3 boot, with the addition of the "wscon"
and related devices that the 05/25 fix brought into play.

As can be seen, the boot finishes, and (entirely as expected) dumps to
single-user mode since rc.conf hasn't been configured. Attempting to issue
the mount command results in exactly what you see... In the middle of
typing it, (no return hit, it just throws up the crash immediately after
the "u" is typed) something blows up, in a fairly spectacular fashion.

Repeatability:
Variably consistent. (How's that for an oxymoron?)
Most recent attempt let me type "mount " before issuing the "Kernel FPU
trap." notice and going into a panic. The one before that let me get "mount
-" typed. Before that allowed me to get "mount -u -". As of yet, I haven't
managed to get the full "mount -u -w /<return>" sequence into the machine
before having the "Kernel FPU trap." notice, register/stack dump, and panic
printed.


Ideas? I'm too much of a rookie to even start guessing.




Don Bruder -  dakidd@sonic.net      <--- Preferred Email - unmunged
I will choose a path that's clear: I will choose Free Will! - N. Peart