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

[Pacho Ramos]

El jue, 29-01-2009 a las 06:50 -0800, Dan Nicholson escribió:
> Meant to get back sooner on this, sorry.
> 
> One issue is that it makes the assumption that the distro has a hdparm
> initscript. None of the distros I've used have had one, so I don't
> think this is universal. What system are you using? It might end up
> being something that's distro specific. Here's what fedora does:
> 
> http://cvs.fedoraproject.org/viewvc/rpms/pm-utils/devel/pm-utils-99hd-apm-restore?view=markup
> 
I am using Gentoo, that provide a hdparm init.d script. It's useful as
can be used for setting other parameters over "-B" stuff (like enable
dma on some old cdrom devices)

El jue, 29-01-2009 a las 07:36 -0800, Pedro R escribió: 
> This hdparm issue is distro specific, i'm sure hdparm upstream will not 
> want to handle it, because honestly they don't have to. 
> 

What problem do you mean? If you refer to "Load_Cycle..." problem, it is 
not exactly a distro problem, it seems
to be a problem with some BIOS and its defaults for hard drives.

> Fixing it in pm-utils is pernicious, because this issue only affects laptops,
>  but i still think it's the best way. 
> 

Well, I am following this issue since it started to be noticed in ubuntu
 and I have seen a few cases where desktop machines were also affected :-)

Anyway, this quick could be used for other purposes, not only "-B" (simply 
see "man hdparm" to see how many options you can use, I know that most of 
systems won't need too many changes over defaults, but there are others 
where they can be needed :-))

> It would be great to include this in pm-utils, since the collateral 
> overhead for desktop computers is not that big either.
> 

I think that it shouldn't "hurt" to desktop users as it's common that people
 who install hdparm want to change any drive parameter (DMA for example) then
, this quirk would allow him/her don't need to re-rerun hdparm after BIOS
 changes defaults while booting or resuming.

Also, the suggested pm-utils quirk won't run hdparm -B 254, it will simply
run an init.d script that will execute hdparm with options chosen by the user

On the other hand, users that don't care about hdparm wouldn't have installed it,
 and quirk would simply skip the run


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

I disagree at this point. I have also read that 128 is better for preventing 
harder problems with hard drive if it would receive a shock (or "knock",
sorry but I am not sure about what word should I use for replacing "golpe" (in spanish))

But, on the other hand, none of my laptops have never fall and I prefer having
safer 254 set all time on my laptop for preveing extra clicks even in battery mode

Also, take care that not all harddrives need the same "-B" parameter, for 
example, with a Dell XPS, 254 is ok but on an Asus laptop I have to use 200 as
nothing between it and 255 seem to have effect (you can see problems like this in 
openSuSE bug report about this issue).

Anyway, I understand your point of view, but I think that this should be managed
 in a different way (for example with an acpi rule?)

What I am simply proposing is the following:

1. At least under gentoo, a hdparm init.d script is provided. It can be 
configured for running hdparm with any option you want, then
it can be used for adjusting, for example, Advanced Power Management
feature (famous "-B"), Query/enable (E)IDE 32-bit I/O support, DMA setting...

Also, maybe this hdparm init.d script could be improved with your suggestions 
about checking battery/ac status for being able to run with different
options depending on it. 

2. The suggested pm-utils quirk simply reruns this init.d script
when resuming for redefining harddrive settings "messed up" by BIOS


> If Pacho Ramos won't mind sending me his hook, i can complete it this way. 
> 

I already sent it to this mailling list:
http://lists.freedesktop.org/archives/pm-utils/2009-January/001871.html

Can be downloaded from:
http://lists.freedesktop.org/archives/pm-utils/attachments/20090118/8db2b38f/attachment.bin 

El jue, 29-01-2009 a las 09:24 -0800, Dan Nicholson escribió: 
> On Thu, Jan 29, 2009 at 7:36 AM, Pedro R <eusou15 at yahoo.com> wrote:
> ...
> 
> 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.
> 

This seems to be caused by BIOS modifying the setting, then, when I reboot the machine
the "wrong" value is chosen again. At least this is what I saw in:
https://bugzilla.redhat.com/show_bug.cgi?id=391671#c3

El jue, 29-01-2009 a las 09:58 -0800, Dan Nicholson escribió: 
> 
> Why doesn't the kernel driver handle this? Having an hdparm hook that
> restores the setting is fine as a short term workaround, but this
> should really be handled by the kernel's suspend framework.
> 
> --
> Dan
> 

I didn't know kernel was supposed to do it. I can send a bug report if you want
Also, this affects to official kernel suspend and tuxonice, then, I am not sure
who would be the culprit (I can also mail to tuxonice mailling list as this is the
suspend mode I use now)

What do you think? 

Thanks a lot :-)