Date: Sun, 03 Jul 2005 01:04:08 -0000 From: Anthony Ginepro <anthony.ginepro@laposte.net> To: =?ISO-8859-1?Q?S=F8ren?= Schmidt <sos@DeepCore.dk> Cc: 'FreeBSD Current' <freebsd-current@freebsd.org>, "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évrier 2005 à 11:07 +0100, Søren Schmidt a écrit : > Anthony Ginepro wrote: > > > ATA mk3 works fine on my system except two things : > > - it seems there's no more atapi-cam support (or it's still WIP ?), > > I dont know the status of that, you need to ask the author/maintainer.. > > > - dumps doesn't work (but never did on my system). > > 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. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1108318113.871.5.camel>