On Tue, Oct 18, 2011 at 6:41 PM, Nicholas A. Bellinger <nab@xxxxxxxxxxxxxxx> wrote: > I'm having no problems with the patch posted for v3.2 review on MT26428 > HCAs > > Can you verify you are actually using this patch, and not your private > tree from github..? The reason is that your tree did not contain the > bugfix below to ib_srpt code that was originally causing problems: > > ib_srpt: Fix bug with chainged SGLs in srpt_map_sg_to_ib_sge > http://www.risingtidesystems.com/git/?p=lio-core-2.6.git;a=commitdiff;h=ea485147563b6555a97dbf811825fbb586519252 Yes, that patch was included - sorry, but I had made another mistake. 3.1-rc10 + ib_srpt + patch below is now working fine here. I noticed only one unusual issue so far (with kernel debugging enabled) and that is that the watchdog thread CPU time was unusually high: root 7 2.3 0.0 0 0 ? S 18:39 0:22 [watchdog/0] root 12 0.6 0.0 0 0 ? S 18:39 0:06 [watchdog/1] The patch I used to backport ib_srpt from LIO-4.1 to kernel 3.1-rc10 is: diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c index 109b412..b3947fe 100644 --- a/drivers/infiniband/ulp/srpt/ib_srpt.c +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -1340,7 +1340,7 @@ static void srpt_put_send_ioctx(struct srpt_send_ioctx *ioctx) WARN_ON(srpt_get_cmd_state(ioctx) != SRPT_STATE_DONE); srpt_unmap_sg_to_ib_sge(ioctx->ch, ioctx); - transport_generic_free_cmd(&ioctx->cmd, 0); + transport_generic_free_cmd(&ioctx->cmd, 0, 0); if (ioctx->n_rbuf > 1) { kfree(ioctx->rbufs); @@ -1899,7 +1899,7 @@ static void srpt_handle_tsk_mgmt(struct srpt_rdma_ch *ch, TMR_TASK_MGMT_FUNCTION_NOT_SUPPORTED; goto process_tmr; } - cmd->se_tmr_req = core_tmr_alloc_req(cmd, NULL, tcm_tmr, GFP_KERNEL); + cmd->se_tmr_req = core_tmr_alloc_req(cmd, NULL, tcm_tmr); if (!cmd->se_tmr_req) { send_ioctx->cmd.se_cmd_flags |= SCF_SCSI_CDB_EXCEPTION; send_ioctx->cmd.se_tmr_req->response = TMR_FUNCTION_REJECTED; Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
