Re: regarding bug #5914 - fs corruption on SATA

[Jens Axboe <axboe@suse.de>]

On Fri, Jan 27 2006, Nicolas Mailhot wrote:
> 
> Le Ven 27 janvier 2006 09:13, Jens Axboe a écrit :
> > On Thu, Jan 26 2006, Nicolas Mailhot wrote:
> >> Le jeudi 26 janvier 2006 à 11:01 +0100, Nicolas Mailhot a écrit :
> >> > Le Jeu 26 janvier 2006 10:21, Jens Axboe a écrit :
> >> > > On Thu, Jan 26 2006, Nicolas Mailhot wrote:
> >> >
> >> > >> What parts can be done one a pre-breakage kernel and what parts on
> >> a
> >> > >> problem kernel (I ask this because a problem kernel will corrupt
> >> > >> basically
> >> > >> any file it writes to, even in single login mode the damage is
> >> > >> significant
> >> > >> so I need to limit the corruption window to minimum).
> >> > >
> >> > > You need a new kernel (after the barrier rework), so 2.6.16-rc1 for
> >> > > instance.
> >> >
> >> > Ok, I'll do the test this evening (CET) with the rawhide/davej
> >> kernel-of
> >> > the day.
> >>
> >> I applied the fua backout patch and the kernel booted beautifully.
> >> Now I guess I need to see if Maxtor released a fixed firmware right ?
> >> (is it possible to change the firmware on a running system ?)
> >
> > If you can get an update firmware, it is usually done by booting from
> > DOS floppy and running a special flash utility from there. Can you send
> > me the hdparm -I /dev/sdX output of the problem drive? I think we should
> > just blacklist it for FUA. This bug is so obscure I think it's a better
> > solution than adding a FUA disable module parameter at this point.
> 
> There is already fairly complete smart info available in
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=177951
> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123604
> https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123605)

I didn't notice the smart info, yes that holds enough information.
Thanks!

-- 
Jens Axboe