6 Feb
2019
6 Feb
'19
1:53 p.m.
From: Mattis Lind
> we've also looked at what's in memory at
that location, and the low
> part of the text segment seems to be correct, but there was junk at
> the top, around the target of the JSR (i.e. at 'csv'). Not just one
> word, but everything around that location was wrong, which would
> suggest to me that the cause is not a simple memory failure there.
> I've suggested to Fritz that we look at that again, to see if what was
> recorded before is accurate
Would it be possible to insert a breakpoint or halt
and run the
program, insert original instruction and single step?
I'm not sure that's going to tell us much: the latest development is that
Fritz looked at the actual memory contents again, and it is once again
trash; _almost_ identical to what was there before:
PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144
but with some extra 010000 bits:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
(It's not clear if this represents a real difference, or if that
front panel issue Fritz mentioned caused the contents to be displayed
incorrectly.)
The exciting thing is that if the latter really is what's in main memory,
that '16700 16152' at the PC of the MM trap could indeed generate the MM trap
we're seeing: it's "MOV 26364, R0", and that address is in segment
(page) 1,
which is only 03500 long....
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news). Which is not
going to be simple, alas, I suspect. I don't think it's the RK11, because
Unix reads the program image into system buffers in low memory, and that's
clearly working OK in the 'sleep;ls' case. (It may not use the exact same
buffers, though...) It then copies it out to the memory where it's going to
execute from, using an MTPI loop. So maybe the memory still has issues, or
maybe the MTPI isn't working with some main memory locations or or or...
Noel
6 Feb
6 Feb
3:54 p.m.
On 2019-Feb-06, at 10:53 AM, Noel Chiappa via cctalk wrote:
I'm not sure that's going to tell us much: the latest development is that
Fritz looked at the actual memory contents again, and it is once again
trash; _almost_ identical to what was there before:
PA:171600: 016162 004767 000224 000414 006700 006152 006702 006144
but with some extra 010000 bits:
PA:171600: 016162 004767 000224 000414 016700 016152 016702 016144
(It's not clear if this represents a real difference, or if that
front panel issue Fritz mentioned caused the contents to be displayed
incorrectly.)
The exciting thing is that if the latter really is what's in main memory,
that '16700 16152' at the PC of the MM trap could indeed generate the MM trap
we're seeing: it's "MOV 26364, R0", and that address is in segment
(page) 1,
which is only 03500 long....
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news). Which is not
going to be simple, alas, I suspect. I don't think it's the RK11, because
Unix reads the program image into system buffers in low memory, and that's
clearly working OK in the 'sleep;ls' case. (It may not use the exact same
buffers, though...) It then copies it out to the memory where it's going to
execute from, using an MTPI loop. So maybe the memory still has issues, or
maybe the MTPI isn't working with some main memory locations or or or...
I haven't followed this in detail enough to know what the configuration and memory
board at play are so maybe
this can be ruled out from your end, but for consideration, what about the refresh
circuitry of the memory board?
Mem diagnostics, unless they explicitly account for it, may not show up problems with
memory refresh
if the loop times are short enough to effectively substitute as refresh cycles, while they
could show up later in
real-world use with arbitrary time between accesses.
Refresh on some early boards/systems was asynchronously timed by monostables or onboard
oscillators
which can drift or fail on the margin/slope. (I don't know what DEC's design
policy was for DRAM refresh).
It might also explain why a number of 4116s were (apparently) failing earlier in the
efforts (if I recall the discussion correctly),
replacing them might have just replaced them with 'slightly better' chips, i.e.
with a slightly longer refresh tolerance.
9:25 p.m.
On 02/06/2019 12:53 PM, Noel Chiappa via cctalk wrote:
If so, i) we're down to one problem (good news), and our problem turns into
finding out how that section of the code got trashed (bad news).
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. It could, of course, be a bad driver or receiver
on the memory board. Might also check the other voltage in
the memory array (+12 or whatever was used internally in the
particular memory) and also look for degraded caps on the board.
Jon
9:55 p.m.
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.
1992
days inactive
1993
days old
3 comments
4 participants
participants (4)
-
bhilpert＠shaw.ca -
elson＠pico-systems.com -
fritzm＠fritzm.org -
jnc＠mercury.lcs.mit.edu