From owner-freebsd-current@FreeBSD.ORG Thu May 6 04:37:09 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 0130716A4CF for ; Thu, 6 May 2004 04:37:09 -0700 (PDT) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19B3E43D53 for ; Thu, 6 May 2004 04:37:06 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])i46Baj4u011141; Thu, 6 May 2004 21:36:45 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i46BaWI2025301; Thu, 6 May 2004 21:36:44 +1000 Date: Thu, 6 May 2004 21:36:31 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-Reply-To: <409948A7.1040100@DeepCore.dk> Message-ID: <20040506212202.O19882@gamplex.bde.org> References: <20040505195425.GA2559@laptop.6bone.nl> <409948A7.1040100@DeepCore.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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: Thu, 06 May 2004 11:37:09 -0000 On Wed, 5 May 2004, [ISO-8859-1] S=F8ren Schmidt wrote: > Mark Santcroos wrote: > > Hi, > > > > I finally took the time to find out why I can't get a coredump on panic= : > > > > ata_controlcmd(&ch->device[MASTER], ATA_FLUSHCACHE, 0, 0, 0); > > > > never returns in ata_shutdown() on my system (dmesg attached). > > > > Commenting it out gives me back my coredumps! ;) > > > > Have you seen this before? > > Nope, but I have seen a few disks that claims to support flush and then > do wierd things when asked to... > > > If not, should we maybe create some blacklist of chips that report that > > they can flush but in reality can't ... > > That would be blacklist of disks then, hmm, I'm not a fan of blacklists > actually, they tend to always be as incorrect and incomplete as not > having any. 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... Panic dumps cannot use either device interrupts or timeouts, not to mention normal locks, since panics may occur in almost any context; in particular they may occur with all interrupts masked and important locks in a bad state. Immediate mode must be used, but it doesn't seem to be, and a comment says that it is only used for other things: % void % ata_queue_request(struct ata_request *request) % { % /* mark request as virgin */ % request->result =3D request->status =3D request->error =3D 0; % if (!request->callback && !(request->flags & ATA_R_REQUEUE)) % =09sema_init(&request->done, 0, "ATA request done"); % % /* in IMMEDIATE_MODE we dont queue but call HW directly */ % /* used only during reinit for getparm and config */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ % if ((request->device->channel->flags & ATA_IMMEDIATE_MODE) && % =09(request->flags & (ATA_R_CONTROL | ATA_R_IMMEDIATE))) { Bruce