Re: Race in MSCP (ra/rx) driver

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

[List threading may be a little weird here.  It will show me as
replying to my own message because Mark's message, the one to which I'm
conceptually replying, didn't reach me.  Looking at my logs, it appears
this is because it was marked as US-ASCII text but contained a 0x11
`character', that not being an ASCII printable.  So I'm replying to my
own list mail and hand-editing it into a reply to Mark, copying from
the mail-index archived copy - which is how I noticed it; I was looking
at port-vax for other reasons.]

> I don't see this potential.  These theoretically infinitely fast
> devices that I'm talking about (MSCP, TMSCP, Network devices) aren't
> engaged by simple device register interactions (like a DL11 or even
> the RH11) but they have to reach into the host's memory and fetch the
> command information and parameters.

For the ONLINE race, yes.  It has to, at a minimum, DMA the ONLINE
command out of host memory and DMA its response back in.

For the init step 4 race, no.  In that race, it takes only one? two?
DMA cycles for the device to get the wrong values out of the host's
memory and everything goes to hell from there.

> 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.

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.
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.)

> 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.)

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