Tejun Heo <htejun@xxxxxxxxx> wrote:
> This really isn't a regression. It's been always like that with libata.
> libata doesn't make devices go into standby mode and shutdown(8) does
> it for libata. The problem here is that libata does issue
> SYNCHRONIZE_CACHE on shutdown. So, the sequence of event is...
>
> 1. shutdown(8) issues SYNCHRONIZE_CACHE followed by STANDBY_NOW
> 2. kernel shutdown starts
> 3. libata shutdown issues SYNCHRONIZE_CACHE
> 4. power goes off
>
> Some drives seem to spin up at step #3 even when its cache is clean and
> power goes off right after the disk finishes the command. So, it's
> really bad when it happens - spin down, spin up followed by immediate
> power off.
>
> SCSI part of the fix is queued in scsi-misc-2.6 tree and libata-dev part
> is acked and waiting to be merged, so the fix will be available in
> 2.6.22. However, it's disabled by default to remain compatible with the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> current behavior and requires userland change to fully fix the problem.
^^^^^^^^^^^^^^^^
It sounds like the Schilling kind of compatibility: "The old burner destroyed
your disk on buffer underruns, therefore the new thing should do the same
instead of giving you a perfectly readable data disk."
Guys, not destroying hardware is _NOT_ bad!
--
Anger, fear, aggression. The Dark Side of the Force are they.
Once you start down the Dark Path, forever will it dominate your destiny.
-- Jedi Master Yoda
Friß, Spammer: QuG4KfL@xxxxxxxxxxxxxxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
