Subject: Installation Problem (MSCP-to-SCSI-Hostadapter?)
To: None <port-vax@netbsd.org>
From: Alfred Schmidt <alf@bree.zwergdomain.de>
List: port-vax
Date: 04/05/2004 22:45:15
Dear Community,

some time ago there was a VAX to be abandoned. Taking pity on it, I took
it home, not knowing what it really is.

After recognizing VMS is not my choice I found NetBSD; excellent. It took
a time, but I managed to boot the machine over the network. But the process
to install NetBSD 1.6.2 to the harddisk was the point where the pain came
in:

Labeling the drive, newfs'ing the slices was not a problem, but I can't
unpack the tarballs. The problem is, after a few files (ususally at /bin/dd
or /bin/date from base.tgz) tar "freezes" up.

Sometimes the entire machine is halted (not even responding to the halt 
button at the panel), sometimes only the tar process isn't continuing. 
Since the serial console was gone unaccessible, I used ssh to connect 
to the vax. As long as the machine was responding, it was no problem 
to kill the login shell with a hangup and get the login prompt back. 

Needless to say, every process becomes also deadlocked if it tries to 
access the harddisk, even ls. (seen about three different runstates
at them)

On the other hand, I tried something like 
dd if=/dev/zero of=/mnt/usr/dummyfile count=10000 
resulting in nothing more than a file named and sized as expected.
making count larger by factor 10 resulted in a full halt after some
time.

So my thoughts were: mad drive, replace it. So I did. Result:
same as before; no difference in behaviour. Still no BSD on the
harddisk.  Reading on the other hand was never a  problem. It 
took nothing but time to dump the disk to the bootserver using dd.

A last hope: the archive of this mailing-list. And right: February
last year, there was a report about an issue much like my problems.

The thing in common: KA650 CPU,
the difference: CMD-220 vs. Dilog SQ739Q, but both MSCP-to-SCSI

Other equipment in "my" machine: M7516 (DELQA), M3106 and a 
Distec AD-converter. 

Someone pointed out, it might be a result of a new memory managment
system introduced by 1.4. Can this be confirmed by now? (I would not 
imagine, a bug like this would not be fixed to 1.6) Might 1.3.x mitigate
my problem? Or are there other alternatives to bring the taste
of Unix to the box? Is there anything else I can try? Did I miss 
something? What have I done, NetBSD has chosen not to be my friend?

kind regards,