linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elias Oltmanns <eo@nebensachen.de>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Mark Lord <liml@rtr.ca>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jeff Garzik <jeff@garzik.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-ide@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [git patches] libata hibernation fixes
Date: Wed, 05 Nov 2008 01:45:54 +0100	[thread overview]
Message-ID: <87abcfdmpp.fsf@denkblock.local> (raw)
In-Reply-To: 4910E240.4000801@shaw.ca

Robert Hancock <hancockr@shaw.ca> wrote:
> Mark Lord wrote:
>> Rafael J. Wysocki wrote:
>
>>> On Tuesday, 4 of November 2008, Linus Torvalds wrote:
>>>> On Tue, 4 Nov 2008, Jeff Garzik wrote:
>>>>> This adds code at a late stage (heading towards -rc4), but does
>>>>> eliminate a particular spin-up overcycling behavior associated with
>>>>> hibernation.
>>>> What does this have to do with hibernation?
>>>> If it's a hibernation-only issue, then there is something wrong. 
>>>
>>> No, it is not.  On some machines it is a power-off issue, on the
>>> others it is
>>> hibernation and power-off issue.
>>>
>>>> Also, if it is an issue for normal power-off as well, then I
>>>> wonder why this isn't an issue on Windows. Does windows not spin
>>>> down disks at all?
>>>
>>> In fact, AFAICS, it is an issue on Windows as well, at least if
>>> other-than-HP-preloaded version of Windows is used.
>>>
>>>> IOW, I really don't think this is correct.
>>>> I _do_ think that correct might be:
>>>>
>>>>  - maybe we just do something odd and different, triggering some
>>>> BIOS    behavior that isn't there under Windows.
>>>>
>>>>    So we should power down thigns differently so that the BIOS.
>>>>
>>>>  - quite possibly: we just should not spin down disks at all, and
>>>> just    flush them and do the "park" command thing. If we're
>>>> _really_ powering    off, the disks will spin down on their own
>>>> when power goes away. Maybe    that's what Windows does?
>>>>
>>>> So I really don't want to pull this, because I want to get more of
>>>> an explanation for why we need to do this at all. I also don't
>>>> think this is even appropriate at this stage in -rc.
>>>>
>>>> Is it a regression? If so, that just strengthens the questions
>>>> above - what did _we_ start doing wrong that this is needed at
>>>> all? Let's just stop doing that, not add some idiotic black-list
>>>> for somethign that _we_ do wrong.
>>>
>>> This is a regression, but from something like 2.6.25 or even earlier.
>>> I think what happened is we started to power-off disks at one point
>>> and these
>>> BIOS-es just don't like that.
>>>
>>> [Note that the issue only appears in _some_ HP boxes, other vendors don't
>>> seem to be affected at all.]
>> .
>>
>> So, what happens if we just don't ever spin them down from the kernel?
>> Presumably they still spin-down normally (HP or otherwise) when the BIOS
>> actually cuts the power at the end of all of this?
>>
>> Just curious..
>
> On many disks (especially laptops) just cutting the power without
> spinning the disk down is a bad thing to do, as it causes an emergency
> head unload which causes much more disk wear than a normal controlled
> unload (which a commanded spindown causes). This is much worse than
> the problem here, where the disk is spun down, spun up and down again.
>
> On these systems, not spinning the disk down is fine because the BIOS
> does it. However this would cause problems on systems where the BIOS
> doesn't do so as it will cause an emergency unload on power-down.

Ah, but do BIOSes just cut power without spinning disks down first?
Pressing the power button on my laptop either at the prompt for the HD
password or in GRUB's menu spins the disk down properly. Isn't that the
BIOS doing its job?

>
> From what I have heard, the problem on the HP laptops is thought to be
> something to do with the disk spinning up and back down when it gets
> an IDLE IMMEDIATE command (from the BIOS' SMI code, or whatever it is)
> when it's already spun down (by the kernel). If that's truly the case
> it's pretty retarded behavior on the disk's part..

IDLE IMMEDIATE is supposed to spin the disk up unless the unload feature
is requested. You are probably thinking of STANDBY IMMEDIATE. If your
theory is correct, then a hdparm -y while the drive is in standby mode
should have a similar effect, i.e. the disk should spin up and down
again right afterwards. Is that the case?

Regards,

Elias

  reply	other threads:[~2008-11-05  0:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.Ast7pgG6P20u1PcyOsfgzoaX5YA@ifi.uio.no>
     [not found] ` <fa.1+JQHm7yjIiZJxAzR0eBPn39a9M@ifi.uio.no>
     [not found]   ` <fa.+bfipgmFkcLlZMtnFL0Ks2zyN8Q@ifi.uio.no>
     [not found]     ` <fa.Iek0GbTZLinM2sOi6+b7bsCgnfs@ifi.uio.no>
2008-11-05  0:01       ` [git patches] libata hibernation fixes Robert Hancock
2008-11-05  0:45         ` Elias Oltmanns [this message]
2008-11-05  2:30           ` Tejun Heo
2008-11-05  9:31             ` Elias Oltmanns
2008-11-05  9:37               ` Tejun Heo
2008-11-05 14:37               ` Robert Hancock
     [not found]   ` <fa.8GbzH83c2CAI53n9dyzVOFugmoc@ifi.uio.no>
     [not found]     ` <fa.hGdpNHQGmXAR19JiGuHxSr9N9CA@ifi.uio.no>
2008-11-05  0:20       ` Robert Hancock
2008-11-05  2:10         ` Mark Lord
2008-11-05  2:24           ` Robert Hancock
2009-01-27  7:31 Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2008-11-04  6:27 Jeff Garzik
2008-11-04 16:29 ` Linus Torvalds
2008-11-04 16:53   ` Rafael J. Wysocki
2008-11-04 16:59     ` Mark Lord
2008-11-04 17:07       ` Rafael J. Wysocki
2008-11-05  2:17         ` Tejun Heo
2008-11-04 20:30   ` Pavel Machek
2008-11-04 21:08     ` Rafael J. Wysocki
2008-11-04 21:12     ` Linus Torvalds
2008-11-05  2:23       ` Tejun Heo
2008-11-05  2:42   ` Tejun Heo
2008-11-10  8:52     ` Tejun Heo
2009-01-02  2:36 ` Tejun Heo
2009-01-05  8:34   ` Jeff Garzik
2009-01-11  5:44   ` Jeff Garzik
2009-01-11 12:43     ` Rafael J. Wysocki
2009-01-18 10:20       ` Frans Pop
2009-01-18 20:25         ` Rafael J. Wysocki
2009-01-18 20:39           ` Jeff Garzik
2009-01-18 20:59           ` Frans Pop
2009-01-18 22:52             ` Rafael J. Wysocki

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=87abcfdmpp.fsf@denkblock.local \
    --to=eo@nebensachen.de \
    --cc=akpm@linux-foundation.org \
    --cc=hancockr@shaw.ca \
    --cc=jeff@garzik.org \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).