> On Feb 7, 2019, at 1:37 PM, Fritz Mueller via cctalk <cctalk@classiccmp.org>
> wrote:
>
>
>> On Feb 7, 2019, at 9:47 AM, Noel Chiappa via cctalk <cctalk@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).
How about a Unibus trace? That would give you the RK11 commands as well as the
data it sends in response.
paul
