On 2/6/19 6:25 PM, Jon Elson via cctalk wrote:
I'm thinking it is bad memory. It seems unlikely bus problems could
alter only ONE BIT per word, so I think it is just a bad memory chip,
and finding multiple words where the 010000 bit is now turned on sure
looks like that kind of problem.
So, there was an issue specifically relating to bit 12 on the front
panel (d'oh!), which I have now cleared up.
Furthermore, the "authoritative" sequence of 16 words obtained from the
front panel last night, after addressing this issue, is:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
PA:171620: 004767 000206 000405 012404 012467 016124 000167 177346
...and, as it turns out, this exact sequence also occurs within the ls
binary, on disk (per "od"):
0004220 016162 004767 000224 000414 016700 016152 016702 016144
0004240 004767 000206 000405 012404 012467 016124 000167 177346
So, the memory there _seems_ fine with the latest info at our disposal.
It looks like the question boils down to either "how did that part of
the binary get to that part of memory?", or "how did we end up executing
out of that part of memory?"
Could still be a memory issue _elsewhere_ that lands us there, of
course... Could also be a translation error lurking in the KT11, or a
CPU bug not found by any of the DEC diagnostic suites.
I will scope the refresh clock when I get home tonight, and I'm planning
on hauling out the logic analyzer for an IR trace this weekend...
--FritzM.
P.S. One idea that popped into my head recently, after a suggestion here
to check the KT11 address translation adders, and my response "but the
diagnostics!"... A bug in one of the carry lookahead generators used
between the bit slices of that adder could cause a mistranslation on
only a fairly selective subset of virtual addresses, and this might
conceivably be missed by the KT11 diagnostics? *IF* that's the case and
we can chase the IR trace upstream to the place of an unlucky
mistranslation, it will be pretty easy to track down then in the hw and fix.
