2024-02-17 Multics Hang at 'CPU Add' During Boot, Part 3

2: 00043:000453 0 000006237120 (LDAQ PR0|6,N*) 000000 620(0) 0 0 0 05
2: 00043:000454 0 400132057120 (SSCR PR4|132,N*) 000120 237(0) 0 0 0 00
2: 00043:000455 0 700044710120 (TRA PR7|44,N*) 000000 057(0) 0 0 0 10
2: 00041:030325 0 600000373100 (EPBP7 PR6|0) 030325 710(0) 0 0 0 00
2: 030326 320050710200 (TRA 320050) 000000 373(0) 1 0 0 00
2: 320050 000346754204 (STI 000346,IC) 320050 710(0) 0 1 0 00

43:455

Segment 43 is bound_priv_1, offset 455 is privileged_mode_ut:455

" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "
"
"       rscr and sscr are called in order to execute the rscr and sscr
"               instructions, respectively. "value" is the output or input argument
"               for these instructions as specified in the processor manual,
"               respectively.

rscr:
        lda     ap|2,*          port number in A
        als     10-3            multiply by 128
        adla    ap|4,*          add in scr_input
        als     3               port*1024 + scr_input*8
        rscr    scas$,al                read controller regs
        staq    ap|6,*          Output value.
        short_return

The return from the rscr call went off into lala land....

Added a instruction trace of CPU C. 17K instructions in, it executing the init_processor code as a result of a connect interrupt. The connect interrupt vector is re-vectored to init_processor (instead of the expected connect_handler code) because the bootload CPU is trying to setup for starting CPU D. As part of that setup, it should signal CPUs B and C that startup code is executing and the need to "stand very still" because vectors are being redirected. Examination of the trace shows that CPU C never received that signal, and was continuing on in the idle process. That process includes a self-connect step. When that connect happened, the init_processor code was executed instead of connect_handler. The init_processor code checks the CPU configuration and sees that the CPU thinks it is CPU C instead of the expected CPU D and signals the boot load processor that there was a configuration error. It is unclear why the bootload CPU is not responding to that signal, but that is not relevant to the problem: why did CPU C not get signaled to "stand very still" while CPU D was being setup for initialization.

I add some code to track the start_cpu code, but that caused the simulator to stop hanging and boot normally; I took that code back out and it still won't hang, so now I have no way of testing the bug.