I've got two problems with NetBSD/sparc.

The first one is rather bizarre, but I swear this is what happened to
me....

I built the NetBSD boot blocks, copied boot to /, ran installboot,
tried to reboot...and it died with "Memory access not aligned" (or some
similar message complaining about a memory alignment error).  So I
figured the boot blocks weren't ready for prime time yet, booted the
thing diskless under SunOS, and reinstalled the old bootblocks I had
been using (which I did think to save first :-).  Recently, I tried
again, and got the same error.  This time, I added a debugging printf
to bootxx.c, recompiled, reinstalled, and everything worked.  I removed
the printf, recompiled, reinstalled, and darned if it didn't work!

So if the NetBSD boot blocks don't work for you, try re-installing them
a couple of times before giving up.  I don't know if it's a matter of
caches not getting flushed or what....

The second one is a bit more serious: the current SCSI driver, at least
as of the kernel I'm using (whose version string says 7 Aug) croaks on
large transfers.  I'm not quite sure what "large" is, but I can give
two data points that I know break it: (a) using dd to attempt to copy
sd0a a whole cylinder at a time, with "dd if=/dev/rsd0a bs=433152", and
(b) trying to read the whole inode area from that filesystem via the
raw device at a single go (dumpfs reports ipg=3200 inopb=64 bsize=8192,
implying the attempted read size was 409600 bytes).  When attempting a
read this large, the process hangs hard.  ps reports a D wait, and
SIGKILL of course won't touch it.  Aside from having a hung process,
the system is fine - for example, it doesn't poison the disk; provided
they use small transfers, other processes can access it just fine.
This hang is reliable; a given transfer size, as far as I can tell,
either always hangs or always succeeds.  (I haven't, though, tried
playing with transfer sizes near the boundary of what works; hanging
the machine that often is too tiresome.)

If someone can tell me how to coax ddb into giving me a kernel stack
trace for a non-curproc process, I'll investigate more.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu