From owner-freebsd-current@FreeBSD.ORG Wed May 5 13:11:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED58216A4CE for ; Wed, 5 May 2004 13:11:29 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B33BC43D3F for ; Wed, 5 May 2004 13:11:29 -0700 (PDT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id 02F6A4EEE1; Wed, 5 May 2004 22:11:28 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id A14344EEE2; Wed, 5 May 2004 22:11:28 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i45KBSVt005165; Wed, 5 May 2004 22:11:28 +0200 Received: (nullmailer pid 2960 invoked by uid 1001); Wed, 05 May 2004 20:11:28 -0000 Date: Wed, 5 May 2004 22:11:28 +0200 From: Mark Santcroos To: =?unknown-8bit?Q?S=F8ren?= Schmidt Message-ID: <20040505201128.GA768@laptop.6bone.nl> References: <20040505195425.GA2559@laptop.6bone.nl> <409948A7.1040100@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409948A7.1040100@DeepCore.dk> User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.009545 / 0.0 / 0.0 / disabled X-RIPE-Signature: cfbc2d20107665b340228df0603683bd cc: current@freebsd.org Subject: Re: ATA_FLUSHCACHE failing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 20:11:30 -0000 On Wed, May 05, 2004 at 10:03:51PM +0200, S?ren Schmidt wrote: > Nope, but I have seen a few disks that claims to support flush and then > do wierd things when asked to... I guess so yes. So this is a disk issue instead of a chip issue? You see, I'm not very familiar with ATA :-) > We should find out why it does not return, my guess is that > it doesn't interrupt and the timeout doesn't fire because we are on the > way down... Any hints where to start looking? I'll keep investigating myself too. Thanks for any help. Mark