On Fri, Apr 08, 2016 at 07:36:14PM -0700, Nicholas A. Bellinger wrote: > Ah, yes. However, TARGET_PROT_DIN_INSERT / TARGET_PROT_DOUT_STRIP > will only be happening in sbc_set_prot_op_checks() if fabric_prot = true > for a backend that does not support PI. > > Eg: fabric_prot is for the special case where the fabric supports PI, > but the backend does not, and the normal feature bits a device would > expose for PI are emulated based upon the fabric protection features. > > Since your backend does support PI, cmd->prot_op should always be > TARGET_PROT_*_PASS regardless. > > The other thing to check is that isert_get_sup_prot_ops() is returning > TARGET_PROT_ALL when tpg->tpg_attrib.t10_pi = true. Ok, it turns out this problem was a second LUN that doesn't support PI. So the reported bug is for a this fabrics_prot case, the scsi_debug LUN was actually doing fine. The root cause seems to be that transport_generic_new_cmd allocates a prot_sg for all protection cases, which causes isert_reg_sig_mr to assign a value to sig_wr.prot even for the strip/insert case, which will then cause mlx5 to blow up. But even when fixing that I run into data compare errors, so there's defintively something deeper hiding here. -- 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
