Date: Mon, 1 Jul 2013 17:57:22 +0000 (UTC) From: Steven Hartland <smh@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r252471 - head/sys/dev/mfi Message-ID: <201307011757.r61HvM22098848@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: smh Date: Mon Jul 1 17:57:22 2013 New Revision: 252471 URL: http://svnweb.freebsd.org/changeset/base/252471 Log: 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 Modified: head/sys/dev/mfi/mfi.c Modified: head/sys/dev/mfi/mfi.c ============================================================================== --- head/sys/dev/mfi/mfi.c Mon Jul 1 17:32:07 2013 (r252470) +++ head/sys/dev/mfi/mfi.c Mon Jul 1 17:57:22 2013 (r252471) @@ -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++; } }
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307011757.r61HvM22098848>