Date: Wed, 15 Mar 2017 06:26:43 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 211713] NVME controller failure: resetting Message-ID: <bug-211713-8-LwFRTYBN6d@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-211713-8@https.bugs.freebsd.org/bugzilla/> References: <bug-211713-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211713 --- Comment #20 from Warner Losh <imp@FreeBSD.org> --- In addition, you can control the timeout period with the sysctl dev.nvme.X.timeout=3DS where S is the number of seconds. The min is 5, max = is 120. The default is 30. It might be helpful to see if setting it lower caus= es this to happen more often or if setting it higher causes it to happen less often. It's possible that we're missing a completion interrupt, or that we get one= and somehow take a code path that doesn't cancel the timeout (though given there were actual I/Os that were aborted, that seems unlikely). Disabling TRIM might also make things not suck so badly. But that wouldn't = help Terry's simple newfs. We had issues with insanely slow TRIMs for a drive fo= r a drive we were evaluating under NDA that might be relevant. We had no issues with newfs, nor with the drive itself once we turned TRIM off in ufs. I couldn't find a 950 PRO, but was able to find a SM961. I'll see if I can recreate this issue on my NUC6. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211713-8-LwFRTYBN6d>