Messages in this thread | | | Date | Wed, 12 May 2004 12:52:24 -0600 | From | "Eric D. Mudama" <> | Subject | Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes" |
| |
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.
-- Eric D. Mudama edmudama@mail.bounceswoosh.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |