[opensuse-factory] CPU frequency scaling doesn't work (RC1).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get a warning (two, actually) in gnome that frequency scaling is unsuported; and the applet says that both cores run at 2.09 GhZ. In 11.2 they run at 1.20. CPU is Intel T4300. This means higher temperature and more battery ussage (it is a laptop). Is this problem known? (test partition of system was upgraded from 11.3 to 11.4 RC1 sucesfully) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAk1V6KoACgkQtTMYHG2NR9WL6QCfSsWcsxta8nSxeIOC4bEjjm/f DvwAmwTRPuFEL6Be97D89cUHYiXbxc9d =7Cyz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
lø., 12.02.2011 kl. 02.55 +0100, skrev Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I get a warning (two, actually) in gnome that frequency scaling is unsuported; and the applet says that both cores run at 2.09 GhZ. In 11.2 they run at 1.20. CPU is Intel T4300.
This means higher temperature and more battery ussage (it is a laptop).
Is this problem known?
https://bugzilla.novell.com/show_bug.cgi?id=653540 In yast2 -> systemservices -> enable cpufreq - works for me //Bjørn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le samedi 12 février 2011, à 08:49 +0100, Bjørn Lie a écrit :
lø., 12.02.2011 kl. 02.55 +0100, skrev Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I get a warning (two, actually) in gnome that frequency scaling is unsuported; and the applet says that both cores run at 2.09 GhZ. In 11.2 they run at 1.20. CPU is Intel T4300.
This means higher temperature and more battery ussage (it is a laptop).
Is this problem known?
https://bugzilla.novell.com/show_bug.cgi?id=653540
In yast2 -> systemservices -> enable cpufreq - works for me
I looked a bit at this, and the issue is that we're calling "fillup_and_insserv -y". According to the doc: -y causes enabling the init-script by default if the package is installed for the first time (not during an update). -Y forcefully enables the service. This means the service is always activated regardless of the setting before an update. So on upgrades, -y won't do anything and people who had pm-utils before this service was added won't have this service enabled by default. I'm pretty sure using -Y is an abuse, since people disabling the service would have to manually disable it again. Any idea on how to best solve this? Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2011-02-13 at 21:04 +0100, Vincent Untz wrote:
-y causes enabling the init-script by default if the package is installed for the first time (not during an update). -Y forcefully enables the service. This means the service is always activated regardless of the setting before an update.
So on upgrades, -y won't do anything and people who had pm-utils before this service was added won't have this service enabled by default. I'm pretty sure using -Y is an abuse, since people disabling the service would have to manually disable it again.
Any idea on how to best solve this?
Have a look at the open-vm-tools package, where we ran into that issue at one point as well (a service got renamed, and we wanted to keep it's state). Dominique PS: Sorry vuntz for the duplicate mail :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2011-02-13 at 21:17 +0100, Dimstar / Dominique Leuenberger wrote:
On Sun, 2011-02-13 at 21:04 +0100, Vincent Untz wrote:
-y causes enabling the init-script by default if the package is installed for the first time (not during an update). -Y forcefully enables the service. This means the service is always activated regardless of the setting before an update.
So on upgrades, -y won't do anything and people who had pm-utils before this service was added won't have this service enabled by default. I'm pretty sure using -Y is an abuse, since people disabling the service would have to manually disable it again.
Any idea on how to best solve this?
Have a look at the open-vm-tools package, where we ran into that issue at one point as well (a service got renamed, and we wanted to keep it's state).
Ups.. actually just checked... we only 'clean up the old mess'... the service is installed with insserv_and_fillup -Y (as we are rather safe in assuming that if you install this package you do want the service.. the package is normally auto dragged in on a virtual machine). Sorry... Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2011-02-13 at 21:04 +0100, Vincent Untz wrote:
Le samedi 12 février 2011, à 08:49 +0100, Bjørn Lie a écrit :
lø., 12.02.2011 kl. 02.55 +0100, skrev Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I get a warning (two, actually) in gnome that frequency scaling is unsuported; and the applet says that both cores run at 2.09 GhZ. In 11.2 they run at 1.20. CPU is Intel T4300.
This means higher temperature and more battery ussage (it is a laptop).
Is this problem known?
https://bugzilla.novell.com/show_bug.cgi?id=653540
In yast2 -> systemservices -> enable cpufreq - works for me
I looked a bit at this, and the issue is that we're calling "fillup_and_insserv -y".
According to the doc:
-y causes enabling the init-script by default if the package is installed for the first time (not during an update). -Y forcefully enables the service. This means the service is always activated regardless of the setting before an update.
So on upgrades, -y won't do anything and people who had pm-utils before this service was added won't have this service enabled by default. I'm pretty sure using -Y is an abuse, since people disabling the service would have to manually disable it again.
Any idea on how to best solve this?
RPM triggers on version numbers of the package itself could probably be used to trigger a one-time "enable" of the service on upgrade and never again later. Here is what we do for systemd, which has to mirror the sysv config to systemd config at the first introduction of systemd service files during an upgrade of an already installed package: http://0pointer.de/public/systemd-man/daemon.html Search for "%triggerun". Kay -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le dimanche 13 février 2011, à 23:07 +0100, Kay Sievers a écrit :
RPM triggers on version numbers of the package itself could probably be used to trigger a one-time "enable" of the service on upgrade and never again later.
Here is what we do for systemd, which has to mirror the sysv config to systemd config at the first introduction of systemd service files during an upgrade of an already installed package: http://0pointer.de/public/systemd-man/daemon.html Search for "%triggerun".
Thanks, it works! Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (5)
-
Bjørn Lie -
Carlos E. R. -
Dimstar / Dominique Leuenberger -
Kay Sievers -
Vincent Untz