Re: KA655 Kernel Compile and Corrupt Object Files

> [...hardware build failes...simh build works...]

Some other thoughts occur to me.  I won't be quoting specific pieces,
because I just don't have the mental oomph to deal with fixing up
paragraph-length lines right now.

Since you can netboot and the kernel runs, apparently fine, I am
inclined to suspect specifically the _write_ channel to the DEQNA.
Maybe do some tests just streaming data over TCP, one direction and
then the other?

My guess is that the "xmit logic died" symptom is probably not related.
Every DEQNA I've used, including real hardware with no evidence of
misbehaviour as well as emulated hardware, has provoked such messages
from NetBSD.

Another thing you might want to do is to objdump -d the simh-built
object files and the hardware-built object files (copy them from the
NFS server direct to simh, maybe, if the NFS server can't objdump -d
VAX .o files directly) and diff them.  If my guess is right, you'll see
the occasional burst of nonsense instructions in the hardware-built
files.  (Given the nature of VAX machine language, there is likely to
be a burst of garbage instructions after the first difference.)

Do you have _any_ local storage on the real hardware?  I'm wondering if
you could build twice, once to NFS and once to something local, and see
if they differ.  As a debugging tactic, maybe even set up a SLIP link
and NFS-mount over that.  It'll be slower than molasses in the dead of
winter, but if you get good builds over it then you'd have a fairly
clear smoking gun saying it's something network-specific.  (I did once
set up a machine to run diskless over SLIP; it was agonizingly slow,
but it eventually did what I wanted.  I just can't recall what that was
any longer - I can't come up with a plausible scenario for having
hardware with no networking the kernel recognized but my still wanting
to get a system on it.  I do still have the code.  It's a kernel build
option AUTOSLIP which takes device name and baudrate; it brings up tap0
internally at boot time and speaks a slightly mutant SLIP which carries
Ethernet packets instead of IP packets.  You then connect the other end
of the serial line to something speaking the same mutant SLIP and able
to bridge to a subnet with netboot set up on it, and tell the kernel to
put root on tap0.)

You might even be able to build to a ramdisk and compare from there,
though probably for only one .o file at a time, since your KA655 isn't
exactly going to have gigs and gigs of RAM available.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B