Date: Mon, 13 Apr 2020 18:57:34 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229745] ahcich: CAM status: Command timeout Message-ID: <bug-229745-227-2AK7d3kzz4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-229745-227@https.bugs.freebsd.org/bugzilla/> References: <bug-229745-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229745 --- Comment #43 from Daniel Bell <daniel@belltech.it> --- (In reply to sec from comment #38) I'm sorry I didn't respond sooner, but for my issue, sec was 100% right: a cold power cycle, as bizarre as that sounded to me, along with the loader.conf tweaks mentioned elsewhere, completely solved my problem despite having the problematic drive/controller combo here. Reboots after editing loader.conf did not help, which is why I originally replied here. As of today, the box in question has been up 60 days with zero errors, zero problems, and a healthy IO load—multiple VMs including Windows VMs, multiple active jails and database engines. I'm no longer planning to add a friendlier HBA unless something changes. I realize this isn't solving everyone's problem, but I thought I should mention this worked for me. % uname -a FreeBSD wyn2018.office.wynnecap.com 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 % uptime 2:47PM up 60 days, 23:45, 1 user, load averages: 0.29, 0.67, 0.76 % dmesg | grep DRDY || echo Groovy. Groovy. -- 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-229745-227-2AK7d3kzz4>