RE: Race in MSCP (ra/rx) driver

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Saturday, August 29, 2020 at 5:51 PM, Mouse wrote:
[...]
> > On a separate and/or related issue, your observation about the
> > MicroVAX2's documented initial Qbus map register state when a MSCP
> > boot is invoked from the >>> prompt seems to be at least slightly
> > wrong.  [...observations under emulation...]
> 
> All I *know* is (a) what my scans of my paper EK-KA630-UG-001 say (I
> believe I quoted that text upthread), and (b) what I observed when adding
> code to the boot-block code I was working with to investigate what the Qbus
> map held.
> 
> As I think I said, it's possible my simulator has a bug that causes my ROM code
> (which I obtained by dumping the ROM from a real KA630 I own) to set up
> the Qbus map wrong.  But then, that's also possible - albeit less likely - with
> simh.
> 
> Possibly related, I note
> 
> > sim> boot
> > Loading boot code from internal ka630.bin
> >
> >
> >
> > KA630-A.V1.3
> >
> > Performing normal system tests.
> >
> >   5..4..3..
> >
> > Tests completed.
> 
> This makes me suspect your "internal ka630.bin" has been modified from the
> original DEC code.  My ROM code, which also calls itself KA630-A.V1.3, does
> tests 7 and 6 before continuing to tests 5, 4, and 3.  So, either there were two
> different versions claiming the same version number, or you've got one
> that's been modified, or simh is broken in that it's somehow causing that
> code to skip tests 7 and 6.
> (Or mine is corrupted, but my real hardware did run tests 7 and 6 back when I
> had it operational.)
>
> This would be neither here nor there, except that it casts more doubt than
> there otherwise would be on the relevance of observations made using it to
> what happens on real hardawre.

It is a slightly modified ROM image, but not to affect the test 7 and test 6.  

> Mind you, I can understand *why* someone might dike out tests 7 and 6;
> they are slow, test 6 especially, when the machine has a lot of RAM.

It seems that the DEC engineers were similarly motivated and the designed
a way to achieve this into the hardware and the ROM.

As it turns out the KA630 has a Boot Diagnostic Register which contains flags 
that influence system behavior.  There is a bit in the register, which if set, causes
the ROM to skip the memory diags.  For just the reason you state, the simh
MicroVAX2 simulator defaults to have this bit set to disable the memory tests.
They can be enabled by SET CPU DIAG=FULL

I think that this bit is presented to the CPU via the connector that passes in
the console port speed and the halt enable switch.

The simh source has the original ROM image in the VAX/ka630_orig.bin file.
The changes to this (to get the one the simulator uses) are indicated in 
VAX/ka630_patch.com.  I suspect that if you compare your ROM image 
to the VAX/ka630_orig.bin, they might actually be the same.

> My emulator addresses that by supporting dumping full emulator state to a
> file and restoring it later; I save after the tests.
> 
> > I'm not suggesting that your fix is inappropriate.
> 
> > I am suggesting that when you create a simulator that has dramatically
> > different timing interactions than what actually happened with the
> > original hardware, you will then be burdened with chasing problems
> > like this on every operating system (and each historical version of
> > that operating system) that ran on the hardware you're simulating.
> 
> Only to the extent that I care about running them.
> 
> I created that simulator for my own use.  If someone else finds it useful,
> great, but that is not its primary use case.  The `infinitely fast device'
> approximation has already let me find two bugs in the NetBSD-derived code
> I've been trying to run on it, so it's had good effects already, quite aside from
> booting faster (albeit only slightly faster, probably not even perceptible on
> human timescales).  (I do have delays in place in the console code, because
> the ROM selftest won't pass without them.  It annoys me, and if I had a good
> way to tell when the selftest is over, I'd eliminate the delays at that point.
> And, if I had the source to the ROM code, I'd address this by fixing it.)

Fair enough.   We've got fundamentally different goals.  

> > I am suggesting that it is far easier to change the simulator to
> > reflect the relative timing interactions that existed on the original
> > hardware.  This change goes in one place (the simulator you're
> > currently working on), rather than trying to dig inside each ancient
> > black-box that was code that worked well enough on the old hardware.
> 
> If I were trying to, to put it loosely, compete with simh, if I were trying to
> simulate a uV2 to the point of running NetBSD, VMS, VAXELN, whatever else
> anyone has cobbled together for it?  Then, yes, I would want to count clock
> cycles (not instructions!) and get all the timing right.  (I would also have to
> drop a small fraction of interprocessor doorbell interrupts when configured
> with auxiliary CPUs lacking the fix for that bug, and probably various other
> bug-compatability measures.)
> 
> That's not its primary use case.  Its primary use case is to be useful to me,
> running VAX code without having to get real VAX hardware running.  (It also
> appears to be useful as a stress test for some aspect of NetBSD I haven't yet
> tracked down.  In at least some of my test runs, it seems to drive the
> underlying system into a peculiar state where userland is *really* slow, but
> the kernel is still ticking over just fine.  It feels almost as though the
> scheduling quantum gets changed to something like a minute.  But it's hard
> to debug, because it happens - when it happens - only after many hours of
> emulator run.)

I hate problems like that.  Good Luck.

- Mark