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 <euso...@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 :-) _______________________________________________ Pm-utils mailing list Pm-utils@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils
