From owner-freebsd-stable@FreeBSD.ORG Sun Feb 13 18:08:40 2005 Return-Path: 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 9912016A4CE; Sun, 13 Feb 2005 18:08:40 +0000 (GMT) Received: from renaissance.homeip.net (m197.net81-67-151.noos.fr [81.67.151.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B36F43D2F; Sun, 13 Feb 2005 18:08:35 +0000 (GMT) (envelope-from anthony.ginepro@laposte.net) Received: by renaissance.homeip.net (Postfix, from userid 1001) id 543752049; Sun, 13 Feb 2005 19:08:34 +0100 (CET) From: Anthony Ginepro To: =?ISO-8859-1?Q?S=F8ren?= Schmidt In-Reply-To: <420DD54D.9020008@DeepCore.dk> References: <42028F29.1030801@DeepCore.dk> <420A1792.900@DeepCore.dk> <1108201829.872.8.camel@renaissance.homeip.net> <420DD54D.9020008@DeepCore.dk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Feb 2005 19:08:33 +0100 Message-Id: <1108318113.871.5.camel@renaissance.homeip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: 'FreeBSD Current' cc: "freebsd-stable@freebsd.org" Subject: Re: UPDATE: ATA mkIII first official patches - please test! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2005 18:08:40 -0000 Le Samedi 12 f=C3=A9vrier 2005 =C3=A0 11:07 +0100, S=C3=B8ren Schmidt a =C3= =A9crit : > Anthony Ginepro wrote: >=20 > > ATA mk3 works fine on my system except two things : > > - it seems there's no more atapi-cam support (or it's still WIP ?), >=20 > I dont know the status of that, you need to ask the author/maintainer.. >=20 > > - dumps doesn't work (but never did on my system). >=20 > Hmm, I'll look into that... Some more info : - I recompiled a kernel with #define ATA_R_DEBUG 0x10000fff in ata-all.h in order to find if the kernel was stuck on an ata operation when dumping. When calling "doadump" with ATA_R_DEBUG there was constant activity (but can't remind well because it was scrolling too fast) and I can even cancel the dump, - Retrying "call doadump" under a kernel without touching ATA_R_DEBUG, it worked eventually once and could be canceled. Most of the time, dump can't be canceled and doesn't progress. Should I open a PR so that the issue can be tracked ? Anthony.