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

From: Eric D. Mudama (edmudama_at_mail.bounceswoosh.org)
Date: 05/12/04

  • Next message: Grover, Andrew: "RE: Hotplug events for system suspend/resume" 
    Date:	Wed, 12 May 2004 12:52:24 -0600
To: Robert Hancock <hancockr@shaw.ca>

    On Wed, May 12 at 0:09, Robert Han*** 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/
  • Next message: Grover, Andrew: "RE: Hotplug events for system suspend/resume"