Mike Christie wrote: > Hannes Reinecke wrote: >> diff --git a/drivers/scsi/scsi_transport_fc.c >> b/drivers/scsi/scsi_transport_fc.c >> index 573ce21..6f39bf4 100644 >> --- a/drivers/scsi/scsi_transport_fc.c >> +++ b/drivers/scsi/scsi_transport_fc.c >> @@ -475,7 +475,8 @@ MODULE_PARM_DESC(dev_loss_tmo, >> "Maximum number of seconds that the FC transport should" >> " insulate the loss of a remote port. Once this value is" >> " exceeded, the scsi target is removed. Value should be" >> - " between 1 and SCSI_DEVICE_BLOCK_MAX_TIMEOUT."); >> + " between 1 and SCSI_DEVICE_BLOCK_MAX_TIMEOUT if" >> + " fast_io_fail_tmo is not set."); >> > > What was the largest timeout value you tried? I think I am hitting a bug > with iscsi where if you pass queue_delayed_work a large enough value it > will overflow and instead of getting 100 minutes you get 1. Well, 0x7fffffff works, 0xffffffff is rejected with -EINVAL. And so should every other value with the top bit set. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- 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
