id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
169	'rcf delete cpu' is simple-minded and misleadiing	canthony	Eric Swenson	"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."	defect	new	minor		Hardcore			rcf bootload interrupt