Date: Tue, 5 Sep 2006 12:06:00 +0200 From: "Patrick M. Hausen" <hausen@punkt.de> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: freebsd-stable@freebsd.org Subject: Re: LSI/amr driver controller cache problem? Message-ID: <20060905100600.GB896@hugo10.ka.punkt.de> In-Reply-To: <20060905073017.GA95687@hugo10.ka.punkt.de> References: <20060901164238.GA66726@hugo10.ka.punkt.de> <44F86AB9.9000002@samsco.org> <20060905073017.GA95687@hugo10.ka.punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, all! > > Also, check the cache > > setting on the drives itself. Maybe the drives are loosing power or > > getting reset while data is in their cache. > > I'm starting to suspect something like this. The controller's setting > for the individual drives' caches is "OFF". But these (Seagate ST3500841NS) > would not be the first ATA/SATA drives to "lie" about their cache for > "performance". Seems like for i in 0 1 2 3 4 5 do megarc -pSetCache -WCE0 -SaveCacheSetting -ch0 -id$i -a0 done did the trick. This is supposed to disable the physical drives' write cache and save this setting in the drives' NVRAM, if supported. I don't know why simply setting the WC to "off" in the controller's BIOS setup tool didn't have the same effect. I'm keeping my fingers crossed ;-) Time to re-enable softupdates and do some more stress testing. Up to now the system survived two times "make installworld && reboot" after I changed the settings. Thanks to the guys keeping the amr driver up-to-date. The Linux "megamgr" utility works just fine. If I find the time, I'll make a port. Regards, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060905100600.GB896>