CAC 2015-10-27

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

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License