mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Eric D. Mudama" <edmudama@mail.bounceswoosh.org>
To: Robert Hancock <hancockr@shaw.ca>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.6 "IDE cache-flush at shutdown fixes"
Date: Wed, 12 May 2004 12:52:24 -0600	[thread overview]
Message-ID: <20040512185224.GA2658@bounceswoosh.org> (raw)
In-Reply-To: <008201c437e7$b1a35160$6601a8c0@northbrook>

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


  reply	other threads:[~2004-05-12 18:54 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.jr282gn.1ni2t37@ifi.uio.no>
     [not found] ` <fa.cmd38j8.1tgg9ro@ifi.uio.no>
2004-05-12  6:09   ` Robert Hancock
2004-05-12 18:52     ` Eric D. Mudama [this message]
2004-05-12 19:55       ` Rene Herman
2004-05-12 21:05       ` Bartlomiej Zolnierkiewicz
2004-05-12 22:27         ` Rene Herman
2004-05-12 21:28       ` Gene Heskett
2004-05-13 17:41         ` Eric D. Mudama
2004-05-10  9:20 Rene Herman
2004-05-10 11:32 ` Gene Heskett
2004-05-10 12:04   ` Rene Herman
2004-05-10 20:28   ` Arjan van de Ven
2004-05-10 19:25 ` Bartlomiej Zolnierkiewicz
2004-05-10 21:13   ` Rene Herman
2004-05-10 21:52     ` Bartlomiej Zolnierkiewicz
2004-05-11  4:56       ` Andrew Morton
2004-05-11  5:17         ` Andrew Morton
2004-05-11 11:24           ` Rene Herman
     [not found]             ` <200405111537.23535.bzolnier@elka.pw.edu.pl>
     [not found]               ` <40A1073E.3030605@keyaccess.nl>
2004-05-11 19:06                 ` Rene Herman
     [not found]                 ` <200405120236.00085.bzolnier@elka.pw.edu.pl>
2004-05-12 14:44                   ` Rene Herman
2004-05-11 21:22             ` Mike Houston
2004-05-11 22:05             ` Bill Davidsen
2004-05-14  3:26           ` Pavel Machek
2004-05-15  0:53             ` Andrew Morton
2004-05-15  0:59             ` Andrew Morton
2004-05-15  1:05               ` Bartlomiej Zolnierkiewicz
2004-05-15  5:53               ` Herbert Xu
2004-05-15  6:16                 ` Andrew Morton
2004-05-17 22:13                   ` Greg KH
2004-05-17 22:55                     ` Andrew Morton
2004-05-14  3:25         ` Pavel Machek
2004-05-11 11:24       ` Rene Herman
2004-05-11 12:56         ` Craig Bradney
2004-05-11 15:51           ` Athanasius
2004-05-11 16:10           ` dobrev
2004-05-12 18:07             ` Bartlomiej Zolnierkiewicz
2004-05-12 18:45               ` dobrev
2004-05-13  0:24                 ` Patrick Wildi
2004-05-13  9:55                   ` dobrev
2004-05-10 21:59     ` Rene Herman
2004-05-10 23:36       ` Mike Houston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040512185224.GA2658@bounceswoosh.org \
    --to=edmudama@mail.bounceswoosh.org \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®