7 Feb
2019
7 Feb
'19
10:42 a.m.
On Feb 7, 2019, at 1:37 PM, Fritz Mueller via cctalk
<cctalk at classiccmp.org> wrote:
How about a Unibus trace? That would give you the RK11 commands as well as the data it
sends in response.
paul
On Feb 7, 2019, at 9:47 AM, Noel Chiappa via
cctalk <cctalk at classiccmp.org> wrote:
So, with UISA0 containing 01614, that gives us PA:161400 + 04200 = PA:165600,
I think. And it wound up at PA:171600 - off by 04000 (higher) - which is
obviously an interesting number.
Thanks, Noel.
...it might be interesting to look at PA:165600
and see what's actually _there_
A sea of zeros, as it turns out.
I'm thinking it might be worth obtaining a full memory dump of the text segment at
the point of fault (I can do this with a small toggle-in program to dump it over the
serial console), , and then compare that to the complete text section in the ls binary.
That would give us more of a clue about whether blocks of memory are duplicated or
swapped, what the size, alignment, and stride of the corrupted blocks is, how many there
are, etc.
I'll get an IR trace out this weekend. Another thing I _could_ do with the LA is an
IO command trace on the RK11 (though that's a lot of probes to hook up to get disk
address, count, and memory address).