Hi Jonathan,
Thanks for your review.
On Thu, Dec 8, 2016 at 10:24 PM, Jonathan Toppins <jtoppins@xxxxxxxxxx> wrote:
> This retry logic looks like a complicated infinite loop, I am not seeing
> where there is a counter or some other mechanism to break out of this
> retry cycle if for some reason the HW stops or some other issue occurs.
> Can you help me understand this section?
>
You are right. This is a bug which could cause a system hang.
cmdq_bitmap is set while sending the commands to FW and this will be cleared
when completion interrupts are received (handled by function
bnxt_qplib_process_qp_event which is a part
"bnxt_re: Add QP event handling" patch in this series).
I missed your mail before sending out v2 patch set. I will include
this change as a bug fix patch
or will fix it while incorporating other review comments in v3 patch set.
Thanks
>> +
>> + /* Cmdq are in 16-byte units, each request can consume 1 or more
>> + * cmdqe
>> + */
>> + spin_lock_irqsave(&cmdq->lock, flags);
>> + if (req->cmd_size > cmdq->max_elements -
>> + ((HWQ_CMP(cmdq->prod, cmdq) - HWQ_CMP(cmdq->cons, cmdq)) &
>> + (cmdq->max_elements - 1))) {
>> + dev_err(&rcfw->pdev->dev, "QPLIB: RCFW: CMDQ is full!");
>> + spin_unlock_irqrestore(&cmdq->lock, flags);
>> + goto retry;
>> + }
>> +
>> + cookie = atomic_inc_return(&rcfw->seq_num) & RCFW_MAX_COOKIE_VALUE;
>> + cbit = cookie % RCFW_MAX_OUTSTANDING_CMD;
>> + if (is_block)
>> + cookie |= RCFW_CMD_IS_BLOCKING;
>> + req->cookie = cpu_to_le16(cookie);
>> + if (test_and_set_bit(cbit, rcfw->cmdq_bitmap)) {
>> + dev_err(&rcfw->pdev->dev,
>> + "QPLIB: RCFW MAX outstanding cmd reached!");
>> + atomic_dec(&rcfw->seq_num);
>> + spin_unlock_irqrestore(&cmdq->lock, flags);
>> + goto retry;
>> + }
--
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
