[Simh] TOPS-10: Nested indirect address limit exceeded

[Timothe Litt]

On 13-May-15 16:48, Cory Smelosky wrote:
> Hello,
>
> I initially thought this was time-dependent, but that only seems to be
> when running the 1988 DEC bootstrap monitor.
>
> BOOT>[1,5]newsys
> [Loading from DSKB:NEWSYS.EXE[1,5]]
>
> MINNIE 14-May-15
> Why reload: halt
> Date: 17-may-2015 ; (testing to see if date related, +1 helps sometimes)
> Time: 16:38
> Startup option: go
>
> ? No KMC-11 for KDP #0. ; (Doesn't affect it. to have it)
>
> MINNIE 16:38:01 CTY system 4097
> Connected to Node MINNIE(11) Line CTY
> [Checking terminal type . . . found VT100]
> .LOGIN 1,2
> .R OPR
>
> Nested indirect address limit exceeded, PC: 000000 (000020000000)
>
> Interestingly, if I NOINITIA, then delete MIC.EXE from DEC: (as
> defined in SYSJOB.INI) the nested indirect address limit issue does
> not crop up.
>
> I would assume it's a bug in the monitor except others have done
> slightly different installs without this issue being reported...and at
> a first glance that does not seem like a correct PC considering what
> was just happening.
>
The hardware has no such limit; it's a SimH artifact.  The hardware
would loop (taking interrupts).  A user mode bug can stop the simulation
- which is a SimH bug that I suppose I should fix someday.  It's not a 1
line fix.

.r ddt
1/ movei 0, at 1
1 $g
should not stop timesharing!

The simh pc history buffer should trace how we get there.  Some examines
should tell us whether it's in fact in user mode.

My guess is that this case a bug in MIC.  It would be easier to fix when
the CPU does the right thing, which is to more or less match the hardware. 

SimH internals make it hard to exactly do that, but here's an approach
that should work without too much disruption.  We keep a limit -
anything over a few dozen is unlikely in real life; a few thousand
should be safe.  But we should treat the condition more like a page fail
than a simulator STOP condition: it can longjmp back (as currently), but
instead of stopping the simulation, do this:
     a) check for user mode.  If user mode, check for interrupts & the
timer queue & restart (the infinite looping) instruction.  That will
burn CPU, but then it can be found and debugged under the OS.  From
SimH's point of view, it's just an internally handled pagefail.

    b) If in exec mode, treat it as a hardware error - say a PF code 36,
hard memory error.  That would cause a trap to the monitor, and with
EDDT (or a dump when EDDT isn't loaded) it's trivial to figure out who's
doing a bad thing.  This would actually be easier to deal with than the
real hardware.  Doesn't change the SImH structure, but reports the error
in a way that will get logged and can be debugged.

I can push this onto my queue, unless Bob (who created this "feature")
gets there first :-)

Meantime, it seems to hurt if you run MIC.  So for now, don't. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150513/c0687a8d/attachment.bin>