poll_mpc notes.
The tape driver is doing a minimal and wonky support for poll_mpc. All of the commands are supported, but they don't necessarily do the right thing.
poll_mpc does a 'read controller main memory' that returns the MPC memory image. The image needs to be populated.
'poll_mpc -debug'
The code works well enough that 'poll_mpc' is able to pull the firmware revision level out of the data stream.
I suspect that an ioa_ enhanced version of poll_mpc is the next step; verify that the data conversion is happening and filling out the
requisite fields.
Tape error on shutdown:
DBG(19335090035)> TAPE DEBUG: IDCW_DEV_CODE 0
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status: 4000
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status control: 0
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status channel command: 0
DBG(19335090035)> TAPE DEBUG: stati 4000
DBG(19335090035)> TAPE DEBUG: IDCW_DEV_CODE 2
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status: 4000
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status control: 1
DBG(19335090035)> TAPE DEBUG: mt_cmd: Request status channel command: 2
DBG(19335090035)> TAPE DEBUG: stati 4000
DBG(19335090035)> ERR ERR: doPayloadChan expected IDCW 10 (12)
control of 1 is undefined (0 terminate, 2 process, 3 marker), so we shouldn't be executing the second IDCW. The problem
is related to the inconsistent usage of control in the PCW.
Console sends control 0; ok, it means it.
Boot tape loader sets control == 0 on reset status command.
FNP sets control == 0
prt sees control == 0 on shutdown