lpfc_nvme_wait_for_io_drain(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– lpfc_nvme_wait_for_io_drain(9) πŸ’–

okay bestie, so this one's from the Kernel API Manual β€” yes, that Kernel API Manual, the big one β€” and it's about the very specific, very dramatic moment when NVMe work items just… gotta go. All of them. At once. 🫢


🌸 NAME 🌸

lpfc_nvme_wait_for_io_drain β€” wait for all NVME wqes to complete ✨

Like, literally just sit there and wait until every single NVME wqe is done. No cap.


πŸ¦‹ SYNOPSIS πŸ¦‹

void lpfc_nvme_wait_for_io_drain (struct lpfc_hba *phba );

πŸŽ€ ARGUMENTS πŸŽ€

  • phba β€” Pointer to HBA context object. that's it, that's the one argument, and it's giving "pointer to the HBA context object" energy πŸ’…

⭐ DESCRIPTION ⭐

so here's the tea β˜• β€” this function flushes all wqes in the nvme rings and frees all resources in the txcmplq. Boom. Cleaned up. Iconic behavior honestly.

But wait, there's a plot twist 😭 β€” this function does NOT issue abort wqes for the IO commands sitting in txcmplq. Nope! They just get returned with IOERR_SLI_DOWN. That's their fate. No abort wqes for them, they simply get handed back with IOERR_SLI_DOWN and that's the whole vibe. πŸ’€

And when does this whole situation happen? This function is invoked with EEH when the device's PCI slot has been permanently disabled. permanently. disabled. yeah. that's the main character moment nobody wants. πŸ™ˆ

fr fr, if you're seeing this called, the PCI slot situation is not cute β€” it's permanently disabled and we're just draining what's left. 🫢

πŸ‘‘ SEE ALSO πŸ‘‘

y'all are gonna want the whole friend group here, so let's list them all β€” no skipping, i would never 🧚


and that's the page bestie!! πŸŽ€βœ¨ this one lives in ./drivers/scsi/lpfc, dated October 2026, and it's filed under lpfc_nvme_wait_for_io_drain(9) β€” mwah, go drain those wqes responsibly, ily πŸ’œπŸŒˆ

πŸ“¦ where this page comes from