I can confirm this bug as well, I'm running Karmic Koala with 2.6.31-19-generic on a Lenovo X61T vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz My system config is 8 GB RAM and P256 SSD disk, noswap (OK, added a 0.5 GB RAM-swap...)
I had noticed that the machine had been very slow lately, occasionally due to the lockup bug which locks the machine for a half or up to a minute occasionally which seems to be present in 2.6.31 as well, it seems to get better though when I stopped running Chrome which seems to be a memory hog. Also there seem to be problem with the disk cache which doesn't seem to be tunable. I definitely don't want it to use all my memory for disk cache. Anyway, now I tested the ondemand cpu scaling, and it doesn't work. As sotirovlyu also commented I've see it go up to 1.6 GHz now and then so I haven't thought about it, but now I've seen that this is not at all load related. OK, for my own as I'm always running the machine on external battery, or power adapter, so the compuer doesn't really know when to switch, this doesn't bother me much as I now added another CPU applet to the panel. Then I can scale each core up down, but it seems as GNOME has treated the interface for this in a strange way. Of course I don't want any authentification question now and then when changing, according this picture http://i.imgur.com/OKQtq.png I found a command which I believed was what GNOME uses /usr/bin/cpufreq-selector and first added the %admin group to the sudoers file, didn't help. Then I added my own id, didn't help then I found that the applet uses a separate configuration file /etc/dbus-1/system.d/org.gnome.CPUFreqSelector.conf and first changed user="root" to group="admin" but the stupid thing then was that I didn't get the frequency selector menu any more. Then I added user="orre" to the config file, and then got the frequency menu back, but now I still got that annoying authority question. I finally though I found a working solution, sudo cpufreq-selector -c 0 -f 800000 but that command is hanging, but now I finally have a working solution, I made a little sudo script that can update the scaling like this echo > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 1200000 echo > /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed 800000 Now I intended to add this to /etc/acpi/events/battery but that script is not called upon when I unplug the power. Shouldn't it? and there is no possibility to run a script from the Power Management Preferences. but I found a flag /proc/acpi/ac_adapter/AC/state I can write a cron script polling, to supervise my battery status. I have the feeling that things are starting to get unnecessary complicated. That works fine, and I'm pleased, but it seems as a lot of things could improve here... So, it seems to be several things not working apart from the ondemand scaling: * the command cpufreq-selector is hanging * the frequency selection applet doesn't care about /etc/sudoers * the /etc/acpi/events/ac is not called upon correctly * the /etc/acpi/events/battery is not called upon correctly -- CPU scaling not working correctly, ThinkPad T43, Ubuntu 9.10 https://bugs.launchpad.net/bugs/519142 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
