6 Feb
2019
6 Feb
'19
10:53 a.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