| Summary: | sys-power/pm-utils: hdparm settings are reset during KDE startup | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Wonko <wonko> |
| Component: | [OLD] KDE | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | minor | CC: | arne.flagge, confabulate, daniel, tomas |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | https://bugs.kde.org/show_bug.cgi?id=248905 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Wonko
2010-08-25 09:49:34 UTC
The thread I mentioned has the information that this happens from KDE-4.4.4 on. I posted in the thread mentioned above. Currently unning KDE-4.4.4 on stable x86. Running '/sbin/hdparm -M 128 /dev/sda' survives through a reboot and is retained if I login into other DMs (e.g. fluxbox) or console, but not if login into KDE, where acoustic management is switched off (it defaults to 254). If I recall correctly this started with the kde-4.4.4 version. Please let me know if you need additional info to troubleshoot this. -- Regards, Mick I had another pm related issue with KDE and it was caused by pm-utils (used by powerdevil). pm-utils sets a lot of pm settings (see /usr/lib/pm-utils/* scripts). Try to disable the harddrive features of pm-utils by: touch /etc/pm/power.d/harddrive and restart KDE. (In reply to comment #3) > I had another pm related issue with KDE and it was caused by pm-utils (used by > powerdevil). pm-utils sets a lot of pm settings (see /usr/lib/pm-utils/* > scripts). Try to disable the harddrive features of pm-utils by: > touch /etc/pm/power.d/harddrive and restart KDE. Thanks, this stopped KDE from interfering with the hdparm settings. -- Regards, Mick This actually relates to bug #257156 if I'm correct. The difference with the original bug is that there is a hdparm script now, it must be handled by the ebuild now. I'll mark this one as a duplicate then. *** This bug has been marked as a duplicate of bug 257156 *** I don't think, the solution in bug #257156 fixes this bug. That bug handles the supend/resume case, while this bug handles the power-on case. The script in question is "power.d/harddrive", which is provided by the pm-utils package itself and won't get obsolete by adding another script in "sleep.d". To handle this bug, I propose to ignore script at the install phase, because the script is a bad default. It is obvious for users of KDE's powerdevil and (GNOME's) upower don't expect, that their sane configuration of hdparm get overwritten by a basic, not flexibel pm script. well, the script is configurable, does powerdevil changes hdd parameters on its own ? (In reply to comment #7) > well, the script is configurable, does powerdevil changes hdd parameters on its > own ? > No, powerdevil doesn't change any harddisk parameter by its own. Also the "power.d/harddisk" script provides basic pm defaults, if you don't change any hdparm parameters. That's all fine. But if you want to change something, there are several points where pm-utils fails: 1) Hdparm parameters apply not until the the pm apps (powerdevil, upower) starts. 2) Users have to move existing hdparm configuration to pm-util. 3) The config file to override the defaults doesn't exists. You have to create it by your own. 4) The new config file is empty. Users have to learn, how to configure pm-util scripts. 5) Config can not be shared. The suspend/resume script of bug #257156 depends on hdparm and its configuration. 6) Admins of server and desktop maschines have to configure both differently. (In reply to comment #8) > (In reply to comment #7) > > well, the script is configurable, does powerdevil changes hdd parameters on its > > own ? > > > No, powerdevil doesn't change any harddisk parameter by its own. > > Also the "power.d/harddisk" script provides basic pm defaults, if you don't > change any hdparm parameters. That's all fine. But if you want to change > something, there are several points where pm-utils fails: > 1) Hdparm parameters apply not until the the pm apps (powerdevil, upower) > starts. that is fine, you most likely have a login manager that should start one of these if you are in a situation where you want pm-utils, otherwise it's admin's work to make sure pm-utils gets triggered on boot (a dbus call in local.start would do the job just fine). > 2) Users have to move existing hdparm configuration to pm-util. I wanted to say something sarcastic but I'll fallback to documentation. Writing something up for the power management guide would be the way to go. > 3) The config file to override the defaults doesn't exists. You have to create > it by your own. same a 2 > 4) The new config file is empty. Users have to learn, how to configure pm-util > scripts. variation of 3, see answer to 2 > 5) Config can not be shared. The suspend/resume script of bug #257156 depends > on hdparm and its configuration. I guess you mean shared between hdparm and pm-utils. We could probably solve that by making a default configuration file wrapping hdparm conf.d but in any case, it still is the same argument as 2 > 6) Admins of server and desktop maschines have to configure both differently. that's entirely up to the admin of the machine, see answer to 1 Sure, it can all by done, but it is a lot of effort to push something, which I would call at the moment a regression. It think is good to have some pm defaults and pm-utils looks like the right app for this task, but without the proper docs and an annoucements of the switch in configuration (harddisk pm is new in pm-utils 1.4), the change is a regression for the uninformed user, see the bug's reporter. So until the work is done, I suggest to ignore the script. KDE is following the freedesktop alias anyway, no need to send all e-mails twice |
