Date: Thu, 16 Apr 2020 11:02:46 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229745] ahcich: CAM status: Command timeout Message-ID: <bug-229745-227-SGQxTVirer@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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229745 --- Comment #51 from Wayne Willcox <wwillcox7@gmail.com> --- Ok have some new information in my case. I commented out from /boot/loader.conf #vfs.zfs.cache_flush_disable=3D"1" I commented out from /boot/device.hints #hint.ahcich.0.sata_rev=3D2 so that I was back to the standard defaults. Backed up the New WD Blue drive model WD30EZRZ using rsnapshot installed the same FreeBSD 12.1 on a New WD RED drive: ada0 at ahcich4 bus 0 scbus4 target 0 lun 0 ada0: <WDC WD30EFRX-68EUZN0 82.00A82> ACS-2 ATA SATA 3.x device ada0: Serial Number WD-WCC4N3SJU005 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors) ada0: quirks=3D0x1<4K> restored the snapshot I created from the Blue drive onto the Red drive and rebooted. Let it run off the Red drive and for the first time it successfully ran overnight without disabling /zroot. It didn't log any timeout errors and t= he work load was the same. So 2 new WD Blue drives had this problem and just switching to a new WD Red seems to have resolved the problem. I intend to monitor the Red drive and = see if it continues to behave properly (I expect it will I have a lot of Red dr= ives in service). Additionally I am going to do some more testing with these dr= ives in a test rig. --=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-229745-227-SGQxTVirer>