[Simh] TOPS-20 4.1 BUGHLT

[Cory Smelosky]

Sent from my iPhone

> On May 10, 2015, at 14:45, Timothe Litt <litt at ieee.org> wrote:
> 
>> On 10-May-15 14:14, Cory Smelosky wrote:
>> 
>> Sent from my iPhone
>> 
>>>> On May 10, 2015, at 13:32, Timothe Litt <litt at ieee.org> wrote:
>>>> 
>>>> On 10-May-15 13:07, Cory Smelosky wrote:
>>>> Hey,
>>>> 
>>>> Trying to figure out if this is an issue with the install or an
>>>> obscure SIMH bug.
>>>> 
>>>> PDP-10 simulator V4.0-0 Beta        git commit id: 3b8c318b
>>>> Listening on port 2020
>>>> 
>>>> BOOT>
>>>> 
>>>> 
>>>> [PS MOUNTED]
>>>> 
>>>> SETSPD: TERMINAL 1-40 SPEED 200
>>>> 
>>>> System restarting, wait...?INVALID CHARACTER IN NUMBER
>>>> ENTER CURRENT DATE AND TIME: 10-MAY-2015 13:02
>>>> 
>>>> YOU HAVE ENTERED SUNDAY, 10-MAY-2015 1:02PM,
>>>> IS THIS CORRECT (Y,N) Y
>>>> WHY RELOAD? OPR
>>>> RUN CHECKD? N
>>>> 
>>>> RUNNING DDMP
>>>> 
>>>> 
>>>> SYSJOB 5(23) STARTED AT 10-MAY-2015 1302
>>>> RUN SYS:ORION
>>>> RUN SYS:QUASAR
>>>> RUN SYS:MOUNTR
>>>> RUN SYS:INFO
>>>> RUN SYS:MAILER
>>>> RUN SYS:MAPPER
>>>> RUN SYS:LPTSPL
>>>> RUN SYS:LPTSPL
>>>> RUN SYS:CDRIVE
>>>> RUN SYS:SPRINT
>>>> JOB 0 /LOG OPERATOR XX OPERATOR
>>>> ENA
>>>> ^ESET LOGIN PSEUDO
>>>> ^ESET LOGIN CONSOLE
>>>> ^ESET OPERATOR
>>>> PTYCON
>>>> GET SYSTEM:PTYCON.ATO
>>>> /
>>>> JOB 1 /LOG OPERATOR XX OPERATOR
>>>> ENA
>>>> RUN SYS:BATCON
>>>> /
>>>> SJ  1: @LOG OPERATOR OPERATOR
>>>> SJ  0: @LOG OPERATOR OPERATOR
>>>> 
>>>> **********
>>>> *BUGHLT "ILMNRF" AT 10-May-2015 13:
>>>> *JOB: 000000000002, USER: OPERATOR
>>>> *ADDITIONAL DATA: 001000746144, 304000000000, 000000537375
>>>> **********
>>>> 
>>>> Config:
>>>> 
>>>> set cpu idle
>>>> set cpu tops-20
>>>> at rp0 tops20-ps-rp06-1.dsk
>>>> at rp1 tops20-ps-rp06-2.dsk
>>>> at rp2 tsu.dsk
>>>> at dz0 2020
>>>> set tim y2k
>>>> set console wru=6
>>>> boot rp0
>>>> 
>>>> I have applied the TSU01 4.1 update.
>>>> 
>>>> Any ideas?  It worked fine until I tried to build kermit.
>>> This is the generic illegal memory reference in the monitor for
>>> TOPS-20.  Could be a reference to an unmapped page; a stray pointer, or
>>> commonly a missing erjmp after a potentially unmapped reference.  There
>>> were lots of patches for various cases, but there's probably not a 'last
>>> bug'.
>> Ahhh. Wonder what caused it? All I recall doing before was building permit.
>> 
>>> The additional data is the pagefail word, flags and pc.
>>> 
>>> The only way to track it down is to get a crash dump and dig in.  (You
>>> might get a clue if you look at the PC with MDDT...)
>> A bit difficult considering I can't get a successful boot. ;)
>> 
>> SIMH's switch register cheat sheet?
>> 
>>> You might also get a clue if you run spear on the error log.
>> Again hindered by an inability to boot. ;)
> Well, we know that TOPS-20 boots on SimH when built from scratch.
> So the monitor or the disk was probably corrupted.
> As usual, you aren't providing enough detail of exactly what you did and
> how/when it fails.

I must stop sending emails about issues before leaving the house!

I had upgraded to TSU01 after installing distribution files and sed/sysdpy. I then defined DOC: in 4-1-config and built Kermit.

> 
> While it could be a SimH issue, I'd start by assuming it's a monitor bug
> and work backwards.
> That's the only way to get close enough to identify an issue, wherever
> it is.

Would a fresh install work best to replicate as well?

> 
> So you, or someone with TOPS-20 expertise can:
>  boot into EDDT and investigate
>  with dbugsw set, stop in MX and determine if one of the programs started
>  by MX or sysjob is triggering the bug.  Since the fault is Job 2, that
> seems likely.
>  set a breakpoint at the bughlt and backtrace.
>  boot an older version of the monitor (assuming you kept one)
>  generate a suitable patch.

I hadn't built a new monitor - I kept the 2020 install tape one.

I was too tired to remember the debug switch to the monitor executable.

> 
> Or since you have backups of all your work, you can just build a new PS,
> restore them and see what happens.

Yeah.

> 
> I don't have the time to debug this, but there are other folks on the
> list who have the necessary skills.
> 
>