ESOS 4.x / SCST 3.9.0 — qla2x00t CTIO PORT_LOGGED_OUT regression on FC-AL direct-attach
Environment:
- ESOS version: 4.4.1_z
- SCST version: 3.9.0_fcaac1b6df162faca42c44fa4419fc6e14110c5d (from strings /usr/sbin/iscsi-scstd)
- Target HBA: QLogic QLE2562 (ISP2532 chipset), 8Gb dual-port
- Initiator HBAs: QLogic cards in Proxmox hosts, qla2xxx in initiator mode
- FC topology: FC-AL direct-attach (no FC switch, arbitrated loop)
Symptom:
After every LIP (loop initialization), all CTIO completions from the target return status 0x10 (PORT_LOGGED_OUT) regardless of command
type. FC sessions ARE created and the loop IS operational (link reports 8Gbps), but every SCSI command (INQUIRY, TEST UNIT READY, etc.)
is immediately rejected with this error. Initiators see the device as inaccessible.
Effect:
- Proxmox hosts (initiators) cannot access FC storage at all
- Hosts with QLogic BIOS scan (Checking Adapter X Loop ID XX) hang indefinitely because the BIOS receives FC-level acknowledgment that a
target is present, sends INQUIRY, gets PORT_LOGGED_OUT in response, and retries forever
Root cause (diagnosed):
The SCST 3.9.0 qla2x00t driver creates the SCST session (calls scst_register_session() or equivalent) approximately 2ms after receiving
the PRLI notification from the QLogic ISP2532 firmware — but before the firmware's internal state machine has completed the PRLI
sequence. The firmware is still finalizing port login state when the initiator's first SCSI commands arrive. Since the firmware considers
the port not fully logged in yet, it rejects all CTIOs with 0x10.
This is a regression from ESOS 3.x (SCST 3.3.x), which handled this correctly — either by deferring session creation until firmware
completion, or by treating 0x10 as a transient retry condition rather than a fatal error.
Confirmation:
- Issue is fully reproducible after every rc.scst restart or ESOS reboot
- unloading qla2x00t on ESOS makes the FC loop dark → Proxmox hosts boot normally (QLogic BIOS sees no target, passes through)
- reloading qla2x00t after hosts are up → sessions created but CTIOs fail identically
- ESOS 3.x USB (SCST 3.3.x) with identical hardware and same scst.conf → FC works perfectly
Workaround (currently deployed):
iSCSI target configured in scst.conf via SCST's iscsi driver. Hosts boot with qla2x00t dark, then connect via TCP iSCSI to the same block
devices. Fully functional but uses the 1GbE management network instead of 8Gb FC.
Suggested fix area:
In qla2x00t's PRLI completion handler — add synchronization to delay SCST session registration until the QLogic firmware signals PRLI
fully complete (not just the initial PRLI ACC). Alternatively, treat CTIO status 0x10 as retryable for a short window post-PRLI rather
than failing immediately.
ESOS 4.x / SCST 3.9.0 — qla2x00t CTIO PORT_LOGGED_OUT regression on FC-AL direct-attach
Environment:
- ESOS version: 4.4.1_z
- SCST version: 3.9.0_fcaac1b6df162faca42c44fa4419fc6e14110c5d (from strings /usr/sbin/iscsi-scstd)
- Target HBA: QLogic QLE2562 (ISP2532 chipset), 8Gb dual-port
- Initiator HBAs: QLogic cards in Proxmox hosts, qla2xxx in initiator mode
- FC topology: FC-AL direct-attach (no FC switch, arbitrated loop)
Symptom:
After every LIP (loop initialization), all CTIO completions from the target return status 0x10 (PORT_LOGGED_OUT) regardless of command
type. FC sessions ARE created and the loop IS operational (link reports 8Gbps), but every SCSI command (INQUIRY, TEST UNIT READY, etc.)
is immediately rejected with this error. Initiators see the device as inaccessible.
Effect:
- Proxmox hosts (initiators) cannot access FC storage at all
- Hosts with QLogic BIOS scan (Checking Adapter X Loop ID XX) hang indefinitely because the BIOS receives FC-level acknowledgment that a
target is present, sends INQUIRY, gets PORT_LOGGED_OUT in response, and retries forever
Root cause (diagnosed):
The SCST 3.9.0 qla2x00t driver creates the SCST session (calls scst_register_session() or equivalent) approximately 2ms after receiving
the PRLI notification from the QLogic ISP2532 firmware — but before the firmware's internal state machine has completed the PRLI
sequence. The firmware is still finalizing port login state when the initiator's first SCSI commands arrive. Since the firmware considers
the port not fully logged in yet, it rejects all CTIOs with 0x10.
This is a regression from ESOS 3.x (SCST 3.3.x), which handled this correctly — either by deferring session creation until firmware
completion, or by treating 0x10 as a transient retry condition rather than a fatal error.
Confirmation:
- Issue is fully reproducible after every rc.scst restart or ESOS reboot
- unloading qla2x00t on ESOS makes the FC loop dark → Proxmox hosts boot normally (QLogic BIOS sees no target, passes through)
- reloading qla2x00t after hosts are up → sessions created but CTIOs fail identically
- ESOS 3.x USB (SCST 3.3.x) with identical hardware and same scst.conf → FC works perfectly
Workaround (currently deployed):
iSCSI target configured in scst.conf via SCST's iscsi driver. Hosts boot with qla2x00t dark, then connect via TCP iSCSI to the same block
devices. Fully functional but uses the 1GbE management network instead of 8Gb FC.
Suggested fix area:
In qla2x00t's PRLI completion handler — add synchronization to delay SCST session registration until the QLogic firmware signals PRLI
fully complete (not just the initial PRLI ACC). Alternatively, treat CTIO status 0x10 as retryable for a short window post-PRLI rather
than failing immediately.