9 Jan
2019
9 Jan
'19
8:19 a.m.
the swappable per-process kernel data does in fact
include pre-computed
contents for all the memory management registers, so we'll be able to
see (from the process core dump) where the code and data segments were.
Uh, no. The copies there are 'prototypes', later modified for actual use by
adding in the actual address in main memory. Still trying to understand how
that works - the code (in sureg() in main.c) is kind of obscure.
Noel
14 Jan
14 Jan
12:18 a.m.
Got to work on this problem a little more this weekend. Worked up some simple standalone
diagnostics to map and test all the memory on my 256K MS11-P. Sure enough, I?m seeing
some stuck bits at various addresses in physical address range 700000-757777.
Need to clean up the diagnostics a bit and add some reporting for a complete picture of
what?s going on, but there?s definitely a smoking gun here...
--FritzM.
6:14 a.m.
On Jan 14, 2019, at 3:18 AM, Fritz Mueller via cctalk
<cctalk at classiccmp.org> wrote:
Got to work on this problem a little more this weekend. Worked up some simple standalone
diagnostics to map and test all the memory on my 256K MS11-P. Sure enough, I?m seeing
some stuck bits at various addresses in physical address range 700000-757777.
Need to clean up the diagnostics a bit and add some reporting for a complete picture of
what?s going on, but there?s definitely a smoking gun here...
--FritzM.
Great, that certainly fits the symptoms.
With RSTS, if there is a specific (and not too large) chunk of memory that is bad, you can
instruct it to ignore that memory. In INIT DEFAULT, memory options, use the LOCK command.
You then specify the memory to ignore as a kW address, or range (like 120k-124k). You
can use the lock command multiple times to lock multiple ranges.
paul
2170
days inactive
2175
days old
2 comments
3 participants
participants (3)
-
fritzm＠fritzm.org -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net