Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"

[Gene Heskett]

On Wednesday 12 May 2004 14:52, Eric D. Mudama wrote:
>On Wed, May 12 at  0:09, Robert Hancock wrote:
>>If this is indeed the case, that those drives don't support the
>> "flush write cache" command, I'd like to see Maxtor's excuse as to
>> why.. I believe that Windows always powers down IDE drives before
>> shutdown, maybe this is because of non-universal support for the
>> "flush write cache" command?
>
>The issue is a bit more subtle, and I'm not making an "excuse" per
>say...
>
>(Not speaking officially for Maxtor, but I'm just trying to help...)
>
>
>As per the email I got from Bart, the drive in question doesn't
>support 48-bit commands.  The wierdness is that it claims to support
>the FLUSH CACHE EXT (0xEA) command.  Obviously, this combination
>doesn't make it safe to issue FLUSH CACHE EXT since the drive will
> not be able to properly report a failing location in the event of a
> failure to flush due to a fatal write fault.  The drive knows a
> FLUSH CACHE EXT command isn't safe, so it aborts that command which
> is the error message you see.
>
>The code that Bart showed me does a '&' on the feature word with the
>required support bits, but uses the result in an 'if' conditional. 
> I believe that means that in C, if either of the bits is set, then
> the 'if' will evaluate to true, which is causing the problem.
>
>The solution (that should work for all drives) would be to test
>properly to make sure the drive reports support for both 48-bit
>commands and FLUSH CACHE EXT, with something like:
>
>  if ((feature & bits) == bits)
>
>then issue that command.  If *either* of these bits is false, then
> the drive should be issued a normal FLUSH CACHE (0xE7) command
> (which is a reasonably standard 28-bit command, and all Maxtor
> drives support, including the models in question.)
>
>Note that this only affects newer drives (last 18 months or so) that
>are <120GB. (Yes, I know that is still a truckload)
>
>There are a gazillion of these in the field (we sell ~60 million
>drives/year?) so I don't believe a firmware "upgrade" or equivalent
>simply is logistically possible, but this inconsistency is going to
> be addressed in future products, I'm making sure of it.
>
>
>If anyone has questions, please don't hesitate to email and I'll do
> my best to help.

Thank you Eric, for such a clear explanation of the problem (I have 
one of those drives and was the one who made the second report I 
believe...  Now it seems that a fix can be written into our driver 
without a lot of fuss, so it becomes a non-issue for us once thats 
filtered thru Andrew and on up to Linus.

My Q for you, is, does M$ already have a similar workaround in their 
drivers?  Just curious. :)

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.22% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/