lpfc_check_fcp_rsp(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

okay bestie, welcome to the lpfc_check_fcp_rsp(9) page straight outta the Kernel API Manual β€” we’re checking the returned fcp_rsp to see if task failed. That’s the whole assignment, and yes, it’s giving β€œlet me verify this response before we make it everyone’s problem.” πŸ’…βœ¨


🌸 SYNOPSIS 🌸

int lpfc_check_fcp_rsp (struct lpfc_vport *vport , struct lpfc_io_buf
*lpfc_cmd );

πŸŽ€ ARGUMENTS πŸŽ€

  • vport β€” The virtual port for which this call is being executed. πŸŒ€
  • lpfc_cmd β€” Pointer to lpfc_io_buf data structure. πŸ“¦

πŸ¦‹ DESCRIPTION πŸ¦‹

This routine checks the FCP RSP INFO to see if the tsk mgmt command succeeded. That’s the plot β€” no extra lore, no invented behavior, just the response info doing its little icon thing. πŸ‘‘

And the return code is literally spelled out like this:

Return code : 0x2003 - Error 0x2002 - Success

So: 0x2003 = Error 😭, and 0x2002 = Success ✨. Keep those two cuties straight and you’re slaying.

lowkey important: this page only says what’s above β€” it checks FCP RSP INFO for whether the tsk mgmt command succeeded, and the return codes are 0x2003 for Error and 0x2002 for Success. No cap. πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

The Kernel file and the whole SEE ALSO squad, exactly as listed β€” every single ref is still here, bestie 🫢:

Kernel file ./drivers/scsi/lpfc/lpfc_scsi.c
lpfc_sli4_set_rsp_sgl_last(9), lpfc_rampdown_queue_depth(9),
lpfc_ramp_down_queue_handler(9), lpfc_scsi_dev_block(9),
lpfc_new_scsi_buf_s3(9), lpfc_sli4_vport_delete_fcp_xri_aborted(9),
lpfc_sli4_io_xri_aborted(9), lpfc_get_scsi_buf_s3(9),
lpfc_get_scsi_buf_s4(9), lpfc_get_scsi_buf(9),
lpfc_release_scsi_buf_s3(9), lpfc_release_scsi_buf_s4(9),
lpfc_release_scsi_buf(9), lpfc_fcpcmd_to_iocb(9),
lpfc_scsi_prep_dma_buf_s3(9), lpfc_bg_err_inject(9),
lpfc_sc_to_bg_opcodes(9), lpfc_bg_err_opcodes(9), lpfc_bg_setup_bpl(9),
lpfc_bg_setup_bpl_prot(9), lpfc_bg_setup_sgl(9),
lpfc_bg_setup_sgl_prot(9), lpfc_prot_group_type(9),
lpfc_bg_scsi_adjust_dl(9), lpfc_bg_scsi_prep_dma_buf_s3(9),
lpfc_scsi_prep_dma_buf_s4(9), lpfc_bg_scsi_prep_dma_buf_s4(9),
lpfc_scsi_prep_dma_buf(9), lpfc_bg_scsi_prep_dma_buf(9),
lpfc_scsi_prep_cmnd_buf(9), lpfc_send_scsi_error_event(9),
lpfc_scsi_unprep_dma_buf(9), lpfc_unblock_requests(9),
lpfc_block_requests(9), lpfc_update_cmf_cmpl(9), lpfc_update_cmf_cmd(9),
lpfc_handle_fcp_err(9), lpfc_fcp_io_cmd_wqe_cmpl(9),
lpfc_scsi_cmd_iocb_cmpl(9), lpfc_scsi_prep_cmnd_buf_s3(9),
lpfc_scsi_prep_cmnd_buf_s4(9), lpfc_scsi_prep_cmnd(9),
lpfc_scsi_prep_task_mgmt_cmd_s3(9), lpfc_scsi_prep_task_mgmt_cmd_s4(9),
lpfc_scsi_api_table_setup(9), lpfc_tskmgmt_def_cmpl(9),
lpfc_check_pci_resettable(9), lpfc_info(9), lpfc_poll_rearm_timer(9),
lpfc_poll_start_timer(9), lpfc_poll_timeout(9), lpfc_queuecommand(9),
lpfc_abort_handler(9), lpfc_send_taskmgmt(9), lpfc_chk_tgt_mapped(9),
lpfc_reset_flush_io_context(9), lpfc_device_reset_handler(9),
lpfc_target_reset_handler(9), lpfc_host_reset_handler(9),
lpfc_sdev_init(9), lpfc_sdev_configure(9), lpfc_sdev_destroy(9),
lpfc_create_device_data(9), lpfc_delete_device_data(9),
__lpfc_get_device_data(9), lpfc_find_next_oas_lun(9),
lpfc_enable_oas_lun(9), lpfc_disable_oas_lun(9)

okay that’s the whole page, bestie 🫢 β€” cute little sign-off from the source/version corner: ./drivers/scsi/lpfc, date stamp: October 2026, and the main character remains lpfc_check_fcp_rsp(9). πŸ’–πŸŽ€

πŸ“¦ where this page comes from