Fix regression in 3.18 caused by e05fe29248 qla2xxx: Honor FCP_RSP retry delay timer field.

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).

---
This fix probably still misses the special case when retry delay wants jiffies to wrap around to 0...

 drivers/scsi/qla2xxx/qla_os.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

index db3dbd9..1df4c66 100644
@@ -735,7 +735,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;

--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Chad, Saurav,

does this look ok to you?

Yes, this looks ok.

Thanks, applied to scsi-for-3.19.