From owner-freebsd-stable@FreeBSD.ORG Tue Sep 5 07:30:20 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 CE2CC16A4E2 for ; Tue, 5 Sep 2006 07:30:20 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19ACB43D46 for ; Tue, 5 Sep 2006 07:30:19 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id k857UI7x005586 for ; Tue, 5 Sep 2006 09:30:18 +0200 (CEST) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.10/8.12.10) with ESMTP id k857UIa9096755; Tue, 5 Sep 2006 09:30:18 +0200 (CEST) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.10/8.12.10/Submit) id k857UHNG096754; Tue, 5 Sep 2006 09:30:17 +0200 (CEST) (envelope-from ry93) Date: Tue, 5 Sep 2006 09:30:17 +0200 From: "Patrick M. Hausen" To: Scott Long Message-ID: <20060905073017.GA95687@hugo10.ka.punkt.de> References: <20060901164238.GA66726@hugo10.ka.punkt.de> <44F86AB9.9000002@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F86AB9.9000002@samsco.org> User-Agent: Mutt/1.5.10i 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: Tue, 05 Sep 2006 07:30:20 -0000 Hi, all! On Fri, Sep 01, 2006 at 11:15:37AM -0600, Scott Long wrote: > It is very arguably a bug in the LSI firmware if it is actually dumping > its cache when a PCI reset occurs, especially if a battery unit is > present. However, I seriously doubt that you will get anyone at LSI to > listen to this problem. Do you get any messages on the console at > shutdown about the amr driver flushing the cache? Just verified - yes: amr0: flushing cache...done amr1: flushing cache...done > 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". >From the settings that are readily available through the controller's and other knobs, I eliminated all: controller cache policy: "WTHRU", drive cache: "OFF", Softupdates: disabled (!). Just to be sure. Installworld, reboot, *bang* unexpected file system inconsistency, run fsck manually ... Any ideas? I'll invest some time researching other people's reports about my particular disk drives. Maybe there's a DOS/Windows tool to disable their cache permanently ... There's a small chance that actually setting the drives' caches to "ON" will help. If the controller is intelligent enough to issue "flush cache" commands to the individual drives and if it is so clever that it only issues this command when the cache is configured "ON". ;-) Thanks, 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