'rcf delete cpu' is simple-minded and misleadiing

[canthony]

With a config deck:

cpu a 7 off dps8 70. 8.
cpu b 6 on dps8 70. 8.
cpu c 5 on dps8 70. 8.
cpu d 4 on dps8 70. 8.
cpu e 3 on dps8 70. 8.
cpu f 2 on dps8 70. 8. a
cpu g 2 on dps8 70. 8. b
cpu h 2 on dps8 70. 8. c

boot stan
rcf add cpu b
rcf add cpu c
rcf add cpu d
rcf add cpu e
rcf add cpu f
rcf add cpu g
rcf add cpu h

rcf delete cpu a

reconfigure: No acceptable bootload CPU would be left.

This is a Multics bug, related to an interaction between the port-expander logic and the interrupt mask assignment logic.

Due to the SCU design, only two CPUs can receive interrupts.

Due to the port expander design, a CPU on a port expander cannot be the bootload CPU.

At bootup, the bootload CPU receives interrupts.

When a CPU is added, it also receives interrupts, taking eligibility from the CPU that was taking the second interrupt slot, if any.

At bootup:

A interrrupts

Add B

A interrupts
B interrupts

Add C

A interrupts
B no longer
C interrupts

For the system I am analyzing, it boots on A and then adds B, C, D, E, F, G, H; so A and H are receiving interrupts.

The delete CPU logic is a bit simple-minded. If you are deleting the boot load CPU, it checks to see if the other interrupt receiving CPU is eligible to be bootload CPU. Since (on this system) G is on a port-expander, it is not eligible and the delete fails with the misleading error message:

reconfigure: No acceptable bootload CPU would be left.

The message is really "the other CPU receiving interrupts cannot be a bootload CPU, so rather then finding a bootload eligible CPU I am giving up."

This demonstrates that the message is wrong:

M-> rcf delete cpu a

reconfigure: No acceptable bootload CPU would be left.
Ready
M-> rcf delete cpu b

0849.2 stop_cpu: Removed CPU B.
Ready
M-> rcf add cpu b

0849.3 start_cpu: Added CPU B.
Ready
M-> rcf delete cpu a

0849.4 stop_cpu: CPU B is now the bootload processor.
0849.4 stop_cpu: Removed CPU A.
Ready

Deleting and adding B has the side-effect of making B the second interrupt receiving CPU, so now A can be deleted and B assigned bootload status.

M-> rzd scs$processor_data 0 10

000042 205002000007 411002000006 411002000005 401002000004
000046 401002000003 401002000042 401002000052 401002000062

Bit 5 in the flag indicating that the CPU is receiving interrupts; now B and C are receiving interrupts.

When A was deleted, an interrupt slot became available, and the list was searched for a processor eligible to receive interrupts and not receiving them; C was the first found and was set to receive interrupts.

The delete cpu code should be able to cope with this situation by attempting to reassign the second interrupt slot to a bootload eligible CPU before giving up, as implied by the text of the error message.

[canthony]

The logic of 'add cpu' with respect to assigning the second interrupt slot to the newly assigned processor may need examination. Does it make sense to take the slot away from a bootload eligible CPU and assign it to a non-eligible CPU?