ISOLTS misses test opportunity

[anonymous]

The ISOLTS process includes instructing the operator to "depress the initialize and clear push button", but fails to verify that memory was actually cleared.

Failure of the operator is clear memory will result in incorrect test behavior, so it is reasonable for ISOLTS to verify that memory was cleared.

Failure of memory being cleared if the button was pressed would be indicative of a configuration or hardware failure, so it is reasonable that ISOLTS verify that was memory was cleared when the opportunity presents itself.

Before loading the PFT tests into the test segment, ISOLTS should check that the test segment is indeed set to all zeros, and if not, report that memory was not zero, indicating operator error, CPU malfunction or SCU malfunction.

Additionally, it should zero the memory before proceeding with the tests.

[canthony]

The assertion the memory is cleared may be false.

The operator instructions read:

1. set all port and initialize enable switches and interlace switches to off.
2. set the assignment switches for all ports to 000.
3. set store size switches to 2222.
4. verify that the mode switch is in vms.
5. depress the initialize and clear push button.
6. set the port enable switch "on" for port "b".

The "initialize and clear" is pressed, all of the enable switches are "off"; this may mean that the memory is inaccessible and would not be cleared.

However, it has been observed that not clearing the memory may make ISOLTS misbehave.

[Eric Swenson]

The proposed check can't work as described, and the proposed zeroing is already done. Recommend closing, with the explanation below.

Regarding what actually happens to the test memory, the order of events in isolts_.pl1 (bound_tolts_):

1. opr_com asks the operator to set the switches and to "depress the initialize and clear push button", then waits for "done".
2. tandd_$create_cpu_test_env runs (reconfig.pl1, then configure_test_cpu.pl1, bound_hc_reconfig). Among other things:
   • it removes the test SCU's memory from the paging pool (pc_abs$remove_core);
   • it fills the lower 256K of that SCU with "STA *, DIS" pairs (pad_mem), and the low 2K of the other non-bootload SCUs too. It then checks those patterns to find where the test CPU's fault answered (rcerr_isolts_wrong_scu, _wrong_scu_cell).
3. isolts_ then clears the 64K work area itself: wseg1 = 0; /* clear out our memory area */ (around line 352), before run_pas loads the PFTs and pas2.

The consequences for the ticket's proposal are:

• No zero check is possible. By the time isolts_ can see the memory, the supervisor has deliberately overwritten it with the STA/DIS pattern, so it is never zero, whether or not the button was pressed. A check would have to be in configure_test_cpu, after the operator's "done" and before pad_mem. As comment 1 points out, "initialize and clear" with all port enables off may not clear the memory anyway, so a non-zero result wouldn't reliably mean operator error.
• The zeroing is already done: the whole 64K work area is set to zero before any test is loaded.
• "Not clearing memory makes ISOLTS misbehave": if that is seen, the cause must be state outside the 64K work area (e.g. the test CPU's cache or registers, or memory above 64K that pas2 references). That would need a specific reproduction, probably on the emulator, where "initialize and clear" is simulated and might not reset everything the hardware did.

We should have configure_test_cpu verify, after its own pad_mem, that the pattern reads back (it partly does, in its error path). That is a memory check under Multics' control, independent of the operator's button.