Date: Sun, 13 Feb 2005 19:08:33 +0100 From: Anthony Ginepro <anthony.ginepro@laposte.net> To: =?ISO-8859-1?Q?S=F8ren?= Schmidt <sos@DeepCore.dk> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@freebsd.org> Subject: Re: UPDATE: ATA mkIII first official patches - please test! Message-ID: <1108318113.871.5.camel@renaissance.homeip.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1108318113.871.5.camel>