Message ID | 18c7d598-93d2-4770-b314-586dec18b9be@CMEXHTCAS2.ad.emulex.com |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
> Increasing the timeout value of write_object command to 60 seconds as > 30 second timeout was found to be not enough for the command to complete. ... > if (!wait_for_completion_timeout(&adapter->flash_compl, > - msecs_to_jiffies(30000))) > + msecs_to_jiffies(60000))) If an operation is likely to take over 30 seconds I'd expect the 'guard timer' to be much longer than 60 seconds. OTOH if an ioctl() call (or similar) into a driver is going to sleep for that long users are going to start getting worried. I'm not sure what the answer is, but some kind of confirmation that the operation is proceeding would be more useful. I presume that the time is taken doing flash sector erases and writes? 30 seconds is still a lot of flash erases. Perhaps the flash code could decrement a counter and wake the user process every time it finishes a sector. The application could then report progress - and the timeout would only need to be long enough for a single sector erase/write. David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c index ce5af9b..488ee6e 100644 --- a/drivers/net/ethernet/emulex/benet/be_cmds.c +++ b/drivers/net/ethernet/emulex/benet/be_cmds.c @@ -2086,7 +2086,7 @@ int lancer_cmd_write_object(struct be_adapter *adapter, struct be_dma_mem *cmd, spin_unlock_bh(&adapter->mcc_lock); if (!wait_for_completion_timeout(&adapter->flash_compl, - msecs_to_jiffies(30000))) + msecs_to_jiffies(60000))) status = -1; else status = adapter->flash_status;