[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4625AF20.7050904@gmail.com>
Date: Wed, 18 Apr 2007 14:39:44 +0900
From: Tejun Heo <htejun@...il.com>
To: Mark Lord <liml@....ca>
CC: Chuck Ebbert <cebbert@...hat.com>, emisca <emisca.ml@...il.com>,
Jan Engelhardt <jengelh@...ux01.gwdg.de>,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-ide@...r.kernel.org, Adrian Bunk <bunk@...sta.de>,
Andrew Morton <akpm@...l.org>
Subject: Re: Loud "pop" coming from hard drive on reboot
Mark Lord wrote:
> Chuck Ebbert wrote:
>> Mark Lord wrote:
>>> I'll patch it locally on my own machines, but what about the tens
>>> of thousands of other Seagate notebook drive owners out there?
>>>
>>
>> This is a problem with Seagate specifically, spinning back up
>> on receipt of some command after spindown?
>
> No, they just seem to be affected worse by it than some other brands.
> The bug is that libata/SCSI now spin-down the drive before the distro's
> scripts are done with it, so it spins down, and then gets spun up again
> by the distro, and then spun down again by the distro.
>
> And along the way, one/both of the two causes a full mechanism "park",
> which is hard on things if abused (like this).
>
> Or at least that's what I recall for it. Tejun?
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.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists