Re: VAX tests?

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

> So, while I will be pursuing this on my own, I'd be interested to
> hear if anyone has any test code I might be able to get my hands on
> [...]

> On another list, someone mentioned the MicroVAX Diagnostic Monitor
> [...]

Someone passed me a copy of the MDM off-list (two different versions,
in fact) - thank you, you know who you are.  This took the form of TK50
copytape images.  In each case, the first file on the tape was,
according to its header, SYSBOOT.EXE.  So I extracted that.  (My
simulator does not yet have working MSCP code, much less TMSCP code, so
I can't do a tape boot.)

First, I tried dropping that into RAM at 0 and jumping to 0.  This
produced "?05 DBL ERR." (first one) or "?08 SCB ERR2." (second one) and
a reset.

So then, I let the POST finish to the >>> prompt, _then_ tell the
simulator to drop the file in, and use the ROM console to jump to it.
This produces "%VAXELN - Insufficient physical memory" and a halt
(first one) or "%uVDOS-F-BOOTERROR, insufficient physical memory" and a
hang (second one).  This happened with 5M in the simulated machine; the
former also happened with 16, as much as it can have.  Obviously
there's something I wasn't setting up right.

Then some memories bubbled up and I checked EK-KA630-UG-001's
description of booting.  Sure enough, it sets up a bunch of data
structures before jumping to the loaded program.

I could, maybe, have set them up by hand.  But I did a netboot with
/r5:200 and looked at them, and a bunch of fields documented as
reserved had nonzero values.  So, instead, I checked SP when it halted,
told the emulator to drop the file there, and then jumped to it with
the console.

With this, the first one says

?04 ISP ERR
    PC = 80003934
>>> 

and the second says

uVDOS V4.0 built on 09-Aug-1990  10:24


?04 ISP ERR
    PC = 800052FA
>>> 

In each case, I repeated it with full simulator tracing turned on.  In
each case, the simulator is taking an ISP invalid halt.  The first one
does this after it executes a bugw instruction, which vectors to a
location that does cmpb $ff,*00(sp), with 00(sp) holding 0, triggering
an access violation, which tries to shift to the interrupt stack.  The
second one does this when, apparently, simply running out of stack and
getting an access violation - the failing instruction is "pushl $2" and
the trapping address is 8007bbfc, just below a page boundary.

Neither one sets the ISP, nor ever goes onto the interrupt stack, so
ISP is still what it was going in, which is the same as the initial SP
(00004c00).  They turn on MAPEN, so an ISP in P0 space is definitely
not valid.

I'm beginning to think I have a subtle bug in some general-purpose
instruction that's corrupting things somehow, with the failures (both
here and NetBSD) being secondary damage.  At the moment all I can think
of is to try to convince SIMH to build, try it, get a trace, and see
where it diverges from my trace.

The MDM has definitely helped ; I now have a much simpler test failure
to work with.  My previous tests involved booting NetBSD and running
for over a billion instructions, including a whole lot of interrupts
and other asynchronous events that would make simulator-level traces
difficult to compare.

/~\ 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