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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713 --- Comment #20 from Warner Losh <imp@FreeBSD.org> --- In addition, you can control the timeout period with the sysctl dev.nvme.X.timeout=S 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 causes 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 for 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. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211713-8-LwFRTYBN6d>