linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Lord <liml@rtr.ca>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: 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: Tue, 04 Nov 2008 11:59:34 -0500	[thread overview]
Message-ID: <49107F76.60107@rtr.ca> (raw)
In-Reply-To: <200811041753.53342.rjw@sisk.pl>

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..

  reply	other threads:[~2008-11-04 16:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04  6:27 [git patches] libata hibernation fixes Jeff Garzik
2008-11-04 16:29 ` Linus Torvalds
2008-11-04 16:53   ` Rafael J. Wysocki
2008-11-04 16:59     ` Mark Lord [this message]
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-19 19:53             ` [PATCH 0/6] Hibernation/poweroff quirks (was: Re: [git patches] libata hibernation fixes) Rafael J. Wysocki
2009-01-19 19:54               ` [PATCH 1/6] Hibernation: Introduce system_entering_hibernation Rafael J. Wysocki
2009-01-19 21:25                 ` Frederic Weisbecker
2009-01-19 21:35                   ` Rafael J. Wysocki
2009-01-19 21:48                     ` Frederic Weisbecker
2009-01-20  7:30                 ` Maciej Rutecki
2009-01-29 13:04                 ` Pavel Machek
2009-01-29 14:51                   ` Rafael J. Wysocki
2009-01-19 19:55               ` [PATCH 2/6] DMI: Introduce dmi_first_match to make the interface more flexible Rafael J. Wysocki
2009-01-19 21:15                 ` Frans Pop
2009-01-20  7:30                 ` Maciej Rutecki
2009-01-19 19:56               ` [PATCH 3/6] SATA: Blacklisting of systems that spin off disks during ACPI power off Rafael J. Wysocki
2009-01-20  7:31                 ` Maciej Rutecki
2009-01-19 19:57               ` [PATCH 4/6] SATA AHCI: Blacklist system that spins " Rafael J. Wysocki
2009-01-20  7:31                 ` Maciej Rutecki
2009-01-19 19:58               ` [PATCH 5/6] SATA Sil: " Rafael J. Wysocki
2009-01-20  7:32                 ` Maciej Rutecki
2009-01-19 19:59               ` [PATCH 6/6] SATA PIIX: " Rafael J. Wysocki
2009-01-19 22:08                 ` Frans Pop
2009-01-20  7:33                 ` Maciej Rutecki
2009-01-18 20:59           ` [git patches] libata hibernation fixes Frans Pop
2009-01-18 22:52             ` Rafael J. Wysocki
     [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       ` Robert Hancock
2008-11-05  0:45         ` Elias Oltmanns
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
  -- strict thread matches above, loose matches on Subject: below --
2009-01-27  7:31 Jeff Garzik

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=49107F76.60107@rtr.ca \
    --to=liml@rtr.ca \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --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).