Remove forced timeout of in-flight commands from mfi_timeout.
While this prevents commands getting stuck forever there is no way to guarantee that data from the command hasn't been committed to the device. In addition older mfi firmware has a bug that would cause the controller to frequently stall IO for over our timeout value, which when combined with a forced timeout often resulted in panics in UFS; which would otherwise be avoided when the command eventually completed if left alone. For reference this timeout issue is resolved in Dell FW package 21.2.1-0000. Fixed FW package version for none Dell controller will likely vary. MFC after: 2 days
This commit is contained in:
parent
7ee2959cb5
commit
5dd4da9f24
@ -3773,12 +3773,15 @@ mfi_timeout(void *data)
|
||||
MFI_PRINT_CMD(cm);
|
||||
MFI_VALIDATE_CMD(sc, cm);
|
||||
/*
|
||||
* Fail the command instead of leaving it on
|
||||
* the queue where it could remain stuck forever
|
||||
* While commands can get stuck forever we do
|
||||
* not fail them as there is no way to tell if
|
||||
* the controller has actually processed them
|
||||
* or not.
|
||||
*
|
||||
* In addition its very likely that force
|
||||
* failing a command here would cause a panic
|
||||
* e.g. in UFS.
|
||||
*/
|
||||
mfi_remove_busy(cm);
|
||||
cm->cm_error = ETIMEDOUT;
|
||||
mfi_complete(sc, cm);
|
||||
timedout++;
|
||||
}
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user