HomeFreeBSD

nvme: start qpair in state RECOVERY_WAITING

Description

nvme: start qpair in state RECOVERY_WAITING

An interrupt happens on the admin queue right away after the reset, so
as soon as we enable interrupts, we'll get a call to our interrupt
handler. It is safe to ignore this interrupt if we're not yet
initialized, or to process it if we are. If we are initialized, we'll
see there's no completion records and return. If we're not, we'll
process no completion records and return. Either way, nothing is
processed and nothing is lost.

Until we've completely setup the qpair, we need to avoid processing
completion records. Start the qpair in the waiting recovery state so we
return immediately when we try to process completions. The code already
sets it to 'NONE' when we're initialization is complete. It's safe to
defer completion processing here because we don't send any commands
before the initialization of the software state of the qpair is
complete. And even if we were to somehow send a command prior to that
completing, the completion record for that command would be processed
when we send commands to the admin qpair after we've setup the software
state. There's no good central point to add an assert for this last
condition.

This fixes an KASSERT "received completion for unknown cmd" panic on
boot.

Fixes: 502dc84a8b6703e7c0626739179a3cdffdd22d81
Sponsored by: Netflix
Reviewed by: mav, cperciva, gallatin
Differential Revision: https://reviews.freebsd.org/D32210

(cherry picked from commit fa81f3731d1a2984a28ae44e60d12a0659b8fd2f)

Details

Provenance
impAuthored on Sep 29 2021, 3:09 AM
mavCommitted on Jan 21 2022, 2:07 AM
Reviewer
mav
Differential Revision
D32210: nvme: start qpair in state RECOVERY_WAITING
Parents
rG9bbd0a7ca999: nvme: Use shared timeout rather than timeout per transaction
Branches
Unknown
Tags
Unknown