Re: Race in MSCP (ra/rx) driver

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

>>>   5..4..3..

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

Ah.  Found it, and I think I know why I wasn't aware of it.  I'm aware
of the BDR's existence, of course, or my emulation would have exploded
very early in startup.  But....

EK-KA630-UG-001 says, when describing the BDR,

09       BDG CD1   Boot  and Diagnostic  Code <01:00>. This 2-bit
08       BDG CD0   read-only   code   reflects   the   status  of
                   configuration   and   display  connector  pins
                   <14:13>.

Those connector pins are described as (yes, the number and name for pin
14 are duplicated)

13      BDG CD0 L   Boot and Diagnostic Code <01:00>. This 2-bit
14      BDG CD1 L   code indicates power-up mode, and is read by
14      BDG CD1 L   software from the BDR.

However, its description of what controls those two pins is, shall we
say, minimal.  When describing the KA630CNF, I find

Switch/Setting

5     6     9     10          Power-Up Mode

Off   Off   On    Off         Normal   operation.   Transmit  line
                              connected. Receive line connected.

On    Off   On    Off         Language inquiry mode. Transmit line
                              connected. Receive line connected.

Off   On    Off   On          Loopback  test  mode  (maintenance).
                              Transmit  line  connected to receive
                              line and console.

On    On    On    Off         Manufacturing   use  only.  Bypasses
                              memory test.

Note:  Other  settings  for  switches 5, 6, 9 and 10 should not be
used.

Presumably this is the last setting, and presumably someone checked and
verified that it doesn't do anything else undesirable.  (Interestingly,
the CK-KA630-A description does not describe its control of those bits;
there is a three-position switch on the panel that preusmably gives
access to the first three settings - the descriptions match well - but
has only three positions.)

The only description I can find of how the switch settings turn into
the connector pin settings is buried in table 2-5, on page 2-8; it says
that BDG CD0 L comes from switch 5 and BDG CD1 L from switch 6, but
doesn't say which position corresponds to which bit value.  But, in my
code, I find

#define BDG_CD_NORMAL   0
#define BDG_CD_LANGINQ  1
#define BDG_CD_LOOPBACK 2
#define BDG_CD_NOMEMTST 3

so apparently at some point I felt reasonably confident of that.

I think I was, at the time, too intimidated by "Manufacturing use only"
and didn't investigate what that last setting does, to the point of
forgetting it even existed.

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

It looks, from the above, as though it's half a bit - one of the four
possible settings for two bits.  Unless the loopback mode also
suppresses the memory tests.

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

I had to git pull; my tree was too old to have VAX/ka630_orig.bin.
But, yes, turns out the _orig file is identical to my image.

Looking at the comments in ka630_patch.com, it looks as though I may
actually have implemented two things simh may not have: console
loopback and memory parity.  In view of what you said about emulating
the hardware warts and all, and changing the emulator instead of the
emulated code, I find this surprising. :-)  Maybe it's just that nobody
ever ran into anything but the ROM code that cared about console
loopback or memory parity?

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

Thank you!  I'm not fond of them myself. :-)  I suspect there is some
kind of resource leak, with the resulting resource exhaustion,
involved, but that's not supported by anything more than some level of
similarity of symptoms to a resource exhaustion bug that afflicts one
of my 1.4T SPARCs (why not the others is one of the mysteries).  I did,
once, manage to recover with "reboot -l -q -n" after shutting down the
emulator.  In most cases, though, it's needed physical intervention.

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