[ewg] RDS - Recovering from RDMA errors

Roland Dreier rdreier at cisco.com
Fri Jan 18 12:41:45 PST 2008

 > When I hit a RDMA error (which happens quite frequently now at rds-stress
 > exit, thanks to the fixed mr pool flushing :) I often see the RDS shutdown_worker
 > getting stuck (and rmmod hangs). It's waiting for allocated WRs to disappear.
 > This usually works, as all WQ entries are flushed out. This doesn't happen
 > when a RDMA transfer generates a remote access error, and that seems to be
 > intended according to the spec.

I don't follow this.  All work requests should generate a completion
eventually, unless you do something like destroy the work queue or
overrun a CQ.  So what part of the spec are you talking about here?

 > I tried destroying the QP first, then we know we can pick off
 > any remaining WRs still allocated. That didn't work, as the card
 > seems to generate interrupts even after the QP is gone. This results
 > in lots of errors on the console complaining about "Completion to
 > bogus CQ".

Destroying a QP should immediately stop work processing, so no
completions should be generated once the destroy QP operation
returns.  I don't see how you get the bogus CQ message in this case --
it certainly seems like a driver bug.  Unless you mean you are
destroying the CQ with a QP still attached?  But that shouldn't be
possible because the CQ's usecnt should be non-zero until all attached
QPs are freed.  Not sure what could be going on but it sounds bad...

 > I then tried to move the QP to error state instead - this didn't
 > elicit a storm of kernel messages anymore, but still I seem to get
 > incoming completions.

The cleanest way to destroy a QP is to move the QP to the error state,
wait until you have seen a completion for every posted work request
(the completions generated after the transition to the error state
should have a "flush" status), and then destroy the QP.

 - R.

More information about the ewg mailing list