Subject: MVME167A success/problems.
To: None <port-mvme68k@netbsd.org>
From: John D. Baker <jdbaker@s55.max1.houston.box.net>
List: port-mvme68k
Date: 05/30/1999 00:57:36
Howdy!  Just joined the list the other day and would like to share my
experiences (good and bad) with the mvme68k port of NetBSD.

I read in the list archives that some folks were hoping to one day run
it on an MVME141 system.  I have hopes of doing so one day as well, and
got interested in the mvme68k port ('147 only at the time) as a possible
springboard for a '141 attempt.

I picked up an old, 4MB MVME147 (no suffixes!) and an 8MB MVME167A
board, with one & one-half MVME712 transition modules (missing one
P2 paddle board) at an electronics flea market.  Both SBCs worked!
I did have to replace the Timekeeper SRAM in the '147--got it from
JDR, imagine that!

Last December, as my Christmas vacation project, I brought up NetBSD
1.3.3.  It went flawlessly!  I installed from QIC150 tape onto a
152MB ESDI hard disk run by an Emulex SD21 SCSI/ESDI controller.

There didn't seem to be any documentation for how to use off-board
(VMEbus) RAM--how to make the kernel see it, but I eventually
figured out the magic words in the NVRAM.  Soon, I had 24MB of
real memory (4MB on board, 12MB from a MicroMemory 6230 board and
8MB from a Motorola MVME224 VME/VSB memory board [from the '141
system]).

While trying to solve a problem related to the fact that I then
had more real memory than swap space (installed without extra
memory), my '147 suddenly died :(.


I knew of other work in progress to support the MVME16x boards and
was reading what I could about them and their installation procedure
and made a point to check NetBSD again.

I was pleased to see that the '167 was now included in the mvme68k
port and I soon had downloaded v1.4.

In spite of the excellent installation instructions, I had to figure
out a few things on my own.  My '167 is so old (167Bug v1.3) that it
did not support network I/O in the debugger.  Also, the ";T" option
of "IOT" does not exist in this version of the debugger.

The '167's SCSI interface seems to be very unforgiving of marginal
devices and excess bus length.  Eventually, I got NetBSD1.4 installed
on a Quantum ELS85S (root, swap and a spare partition) and a Quantum
P105S (/usr).  I wanted more space so I could install other things,
but attaching external disk boxes (maintaining proper termination
at all times) would eventually cause the system to fail with the SCSI
controller complaining about some non-existent target not ready.


Ultimately, I began re-installing the system from scratch on a
comfortably large disk that appeared to fully cooperate with
the system.

That's when I started running into problems.  The preliminary install
(booting from tape, partitioning and labelling the disk, and installing
the miniroot went as well as could be expected.  It was while I was
installing the sets (over NFS) that I kept running into MMU Faults.

I gave up briefly and turned the machine off.  Then, I read the other
accounts in the mailing-list archive--that people had experienced
panics due to an MMU Fault.  I was experiencing the same thing,
albeit somewhat later in the process than the others.

I turned the machine back on and ran the 167Bug MMU test.  It passed.
I ran the full suite of tests.  It passed all of them.  I started
to install from scratch again...

This time, it completed without problem!  I even installed the X11R6
packages.

Soon thereafter, I was logged in and setting up some prefered items
when the machine spontaneously panicked, again with an MMU Fault.

I am going to re-install from scratch again soon and keep an eye out
for the MMU Fault panic so I can provide some input on this problem.

-- 
John D. Baker                                       I hear, and I forget.
jdb8042@blkbox.com                                 I see, and I remember.
http://www.blkbox.com/~jdb8042/                   I do, and I understand.
Amiga, OS/2, Linux -- The cure for M$.          - Ancient Chinese Proverb