| Message ID | 20210211185742.50143-5-tyreld@linux.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | ibmvfc: hard reset fixes | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/merge (626a6c3d2e20da80aaa710104f34ea6037b28b33) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/next (6895c5ba7bdcc55eacad03cf309ab23be63b9cac) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linus/master (92bf22614b21a2706f4993b278017e437f7785b3) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/fixes (24321ac668e452a4942598533d267805f291fdc9) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linux-next (1e0d27fce010b0a4a9e595506b6ede75934c31be) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
On 2/11/21 12:57 PM, Tyrel Datwyler wrote: > diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c > index ba6fcf9cbc57..23b803ac4a13 100644 > --- a/drivers/scsi/ibmvscsi/ibmvfc.c > +++ b/drivers/scsi/ibmvscsi/ibmvfc.c > @@ -5670,7 +5670,7 @@ static int ibmvfc_register_scsi_channel(struct ibmvfc_host *vhost, > > irq_failed: > do { > - plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); > + rc = plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); > } while (rc == H_BUSY || H_IS_LONG_BUSY(rc)); Other places in the driver where we get a busy return code back we have an msleep(100). Should we be doing that here as well? Thanks, Brian
On 2/16/21 6:58 AM, Brian King wrote: > On 2/11/21 12:57 PM, Tyrel Datwyler wrote: >> diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c >> index ba6fcf9cbc57..23b803ac4a13 100644 >> --- a/drivers/scsi/ibmvscsi/ibmvfc.c >> +++ b/drivers/scsi/ibmvscsi/ibmvfc.c >> @@ -5670,7 +5670,7 @@ static int ibmvfc_register_scsi_channel(struct ibmvfc_host *vhost, >> >> irq_failed: >> do { >> - plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); >> + rc = plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); >> } while (rc == H_BUSY || H_IS_LONG_BUSY(rc)); > > Other places in the driver where we get a busy return code back we have an msleep(100). > Should we be doing that here as well? Indeed, and actually even better would be to use rtas_busy_delay() which will perform the sleep with the correct ms delay, and marks itself with the might_sleep() macro. -Tyrel > > Thanks, > > Brian >
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c index ba6fcf9cbc57..23b803ac4a13 100644 --- a/drivers/scsi/ibmvscsi/ibmvfc.c +++ b/drivers/scsi/ibmvscsi/ibmvfc.c @@ -5670,7 +5670,7 @@ static int ibmvfc_register_scsi_channel(struct ibmvfc_host *vhost, irq_failed: do { - plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); + rc = plpar_hcall_norets(H_FREE_SUB_CRQ, vdev->unit_address, scrq->cookie); } while (rc == H_BUSY || H_IS_LONG_BUSY(rc)); reg_failed: ibmvfc_free_queue(vhost, scrq);
The H_FREE_SUB_CRQ hypercall can return a retry delay return code that indicates the call needs to be retried after a specific amount of time delay. The error path to free a sub-CRQ in case of a failure during channel registration fails to capture the return code of H_FREE_SUB_CRQ which will result in the delay loop being skipped in the case of a retry delay return code. Store the return code result of the H_FREE_SUB_CRQ call such that the return code check in the delay loop evaluates a meaningful value. Fixes: 9288d35d70b5 ("ibmvfc: map/request irq and register Sub-CRQ interrupt handler") Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> --- drivers/scsi/ibmvscsi/ibmvfc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)