qla2xxx: fix busy wait regression

Commit e05fe29248 (qla2xxx: Honor FCP_RSP retry delay timer field.)
causes systems to busy-wait for about 3 minutes after boot prior to
detecting SAN disks.

During this wait period one kworker is running full-time
(though /proc/<pid>/stack has no useful data). Another kworker is
waiting for IO to complete during that whole time period.

Looking at drivers/scsi/qla2xxx/qla_os.c, fcport->retry_delay_timestamp
has a special value of 0 though that 0 value forces system to wait when
jiffies is very large value (e.g. 4294952605 - "negative" value when
signed on 32bit systems).

Signed-off-by: Bruno Prémont <[email protected]>
Acked-by: Chad Dupuis <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 12ca291c1380845e45a40b0b4f5f4dd3356ab429..cce1cbc1a9276f4492d6efa16996313c00daabd6 100644 (file)
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -734,7 +734,9 @@ qla2xxx_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
         * Return target busy if we've received a non-zero retry_delay_timer
         * in a FCP_RSP.
         */
-       if (time_after(jiffies, fcport->retry_delay_timestamp))
+       if (fcport->retry_delay_timestamp == 0) {
+               /* retry delay not set */
+       } else if (time_after(jiffies, fcport->retry_delay_timestamp))
                fcport->retry_delay_timestamp = 0;
        else
                goto qc24_target_busy;