>
> 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);
}
...
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
