From owner-freebsd-stable@FreeBSD.ORG Thu Sep 7 17:09:15 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED6AE16A4DD for ; Thu, 7 Sep 2006 17:09:15 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1520C43D55 for ; Thu, 7 Sep 2006 17:09:09 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 07 Sep 2006 10:06:35 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id k87H99d3030086; Thu, 7 Sep 2006 10:09:09 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id k87H98mG030081; Thu, 7 Sep 2006 10:09:08 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200609071709.k87H98mG030081@ambrisko.com> In-Reply-To: <20060905100600.GB896@hugo10.ka.punkt.de> To: "Patrick M. Hausen" Date: Thu, 7 Sep 2006 10:09:08 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: LSI/amr driver controller cache problem? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2006 17:09:16 -0000 Patrick M. Hausen writes: | > > 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. That would be great. I'd discourage the idea of MegaMon though since it leaks shared memory and exits unless LSI has finally fixed it. So monitoring is a pain. I guess a watcher script would be okay but it has a nasty habit of reporting prior errors every time it starts :-( We have a native local tool that works but we can't re-distribute it. The mfi driver doesn't have this issues since the driver reports all events directly. However, MegaCli doesn't actually create or delete a RAID (even with Linux). I have patches in the wings that deals with discovery while the system is up but we need clearance on them. Doug A.