Re: DEQNA on MicroVax II

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> I am trying to resurrect an old microVax II and get NetBSD running on
> it.

> I have a blank disk, a TK70, and a DEQNA.

> (Last month's attempt to netboot failed as I could not get the linux
> server to respond properly. (It kept saying it could not find
> mopboot.sys when it was right there in the directory)

Maybe try NetBSD as the netboot server?  Of course, that's assuming you
have a spare machine, or at least a spare disk for the hardware you
currently have Linux on, or some such.

> Anyway, I found an old floppy with NetBSD 1.2 on it.  I can boot and
> init the disk as ra81, but when it goes to download install sets it
> fails because the DEQNA cannot access the gateway.

> I tried pinging the gateway from the NetBSD command prompt and get no
> reply, but if I ping the MV II from another computer it responds just
> fine, so I know the DEQNA is transmitting and receiving.

You don't say whether you checked this, and it's a long shot in any
case, but it strikes me as *possible* that some other machine on the
LAN is using the address you think the uV2 is using.  After all, all
your ping from elsewhere truly says is that *something* is answering at
that address. So maybe try something like pinging it from elsewhere and
then unplugging the Ethernet (to verify that it stops answering), to
check that it truly is the uVAX that you're talking to?

I also have a fuzzy memory that there was something odd with DEQNAs and
minimum packet sizes.  I once had an NFS mount that would fail to
transfer files of certain sizes; turned out it failed exactly when the
last frag of an NFS response was too small.  (Dealt with by mounting
rsize=1024,wsize=1024, so bulk data was never fragmented.
Non-fragments always had enough headers they never tickled the
problem.)  Something like 60 bytes versus 64 bytes.

Another potential solution occurs to me.  It would execrably slow, but
if you're willing to wait a few days for the bits to trickle over, you
could use SLIP on the console serial port.  (Or, if you have a Qbus
serial card, though you didn't mention any such.)  I once did that
under other circumstances.  I don't remember full details; I think it
was a machine that could netboot but whose Ethernet hardware was not
understood by NetBSD.  At any rate, I built a kernel that came up with
SLIP running on one serial port and managed to get it working that way.
(NFS over a serial port works, maybe, but is seriously slow.)  You at
least wouldn't need to go that far, since you already have a working,
albeit old, NetBSD boot setup.  (I suggest SLIP instead of PPP both
because it has slightly lower overhead on the wire, for most content,
and because it is significantly easier to set up for a
manually-configured one-off like this.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B