>
> >
> > Do you have any thoughts on debugging this? Turning on isert debug is bad
> > because the IO load is very high. I sort of need something that I can do after it
> > gets stuck. So I can change the wait_for_completion() to a
> > wait_for_completion_timeout() and if it times out, go figure out what it is
> stuck
> > on.
>
> This snipit from isert_put_cmd() looks interesting:
>
> ...
> /*
> * Check for special case during comp_err where
> * WRITE_PENDING has been handed off from core,
> * but requires an extra target_put_sess_cmd()
> * before transport_generic_free_cmd() below.
> */
> if (comp_err &&
> cmd->se_cmd.t_state == TRANSPORT_WRITE_PENDING) {
> struct se_cmd *se_cmd = &cmd->se_cmd;
>
> target_put_sess_cmd(se_cmd);
> }
> ...
Hey Sagi,
I found my bug: If a wr chain is posted to iw_cxgb4 and needs to be flushed, only the first wr in the chain was being flushed. The rest never completed. This completion leak was causing the failure to deref IO commands...
Steve.
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
