[Pm-utils] Quirk for running hdparm after resume from suspend and hibernate

[Pedro R]

--- On Thu, 29/1/09, Dan Nicholson <dbn.lists at gmail.com> wrote:

> From: Dan Nicholson <dbn.lists at gmail.com>
> Subject: Re: [Pm-utils] Quirk for running hdparm after resume from suspend and  hibernate
> To: eusou15 at yahoo.com
> Cc: pacho at condmat1.ciencias.uniovi.es, pm-utils at lists.freedesktop.org
> Date: Thursday, 29 January, 2009, 8:54 PM
> On Thu, Jan 29, 2009 at 7:36 AM, Pedro R
> <eusou15 at yahoo.com> wrote:
> > Sorry for coming into the discussion like this, but i
> joined this mailing list because of exactly the same
> problem.
> >
> > This hdparm issue is distro specific, i'm sure
> hdparm upstream will not want to handle it, because honestly
> they don't have to. Fixing it in pm-utils is pernicious,
> because this issue only affects laptops, but i still think
> it's the best way.
> >
> > This is a major issue going on since 2005 and nobody
> seems to want to get their hands dirty fixing it. It would
> be great to include this in pm-utils, since the collateral
> overhead for desktop computers is not that big either.
> >
> > Anyway the hook should be executed on resume (but not
> on hibernate / standby) and on power change: battery ->
> ac adaptor and ac adaptor -> battery, because when on
> battery the setting should be -B 128 (because of physical
> shocks - for an explanation refer to the load_cycle_count
> issue on google) and on ac power it should be -B 254. To do
> this, the hook should not rely on other than the kernel
> itself. Like this:
> >
> >        if cat /proc/acpi/ac_adapter/ACAD/state | grep
> 'off-line' ; then
> >          hdparm -B 128 $dev
> >        else
> >          hdparm -B 254 $dev
> 
> But the AC adaptor state has nothing to do with suspending.
> If you
> really wanted to do this, wouldn't it be better to have
> a service
> listen to AC adaptor events on HAL?
> 

When the computer comes out of suspend, it is always on -B 128 mode, hence the need for a power.d and sleep.d hook. 
It could be done as you said, but it's much more complicated than using this simple check for ac adapter presence (if the adapter is not present, then it is on battery). 


> Back to the more general issue, why does the drive drop the
> Advanced
> Power Management setting when suspending? This really
> sounds like a
> kernel bug to me. This is exactly the type of state that
> should be
> saved by the driver to be restored when resuming.
> 
> --
> Dan

Yes the drive drops the setting...