Doesn't detect CPU frequency

[Pascal d'Hermilly]

Binary package hint: kde-guidance-powermanager

I have an Intel Celeron M 1.6 from August 2006.

My problem is that the power manager applet says my frequency is 0 mhz

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Intel(R) Celeron(R) M CPU 420 @ 1.60GHz
stepping : 8
cpu MHz : 1600.103
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe constant_tsc up pni monitor tm2 xtpr
bogomips : 3204.98
clflush size : 64

[Pascal d'Hermilly (pascal-tipisoft)]

BTW, I'm running Herd 5

[Pascal d'Hermilly (pascal-tipisoft)]

Confirmed with Feisty Beta 1

[Luis Alberto Pabón (copong)]

Same problem here. I am running Feisty Beta (fully updated as of today).

The applet began reporting 0MHz after I dist-upgraded yesterday (the previous upgrade was on friday). There was a new kernel involved.

The applet used to let me change the power profile, not anymore.

CPUFREQ scaling seems to be running fine. The CPU is running in dynamic mode (it's running at 800 MHz now, will run at 1.7GHz when needed). The correct info appears on /proc/cpuinfo, and kdesensors will report correctly the CPU freq.

Laptop will run in powersave when unplugged. it's like the kde applet doesn't know where to get the CPU freq from.

This is a VAIO laptop with an Intel Centrino chipset.

luis@ordenata:~$ uname -a
Linux ordenata 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

luis@ordenata:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Pentium(R) M processor 1.73GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up est tm2
bogomips : 1598.20
clflush size : 64

[Luis Alberto Pabón (copong)]

I just found something weird, might it be related?

The folder /sys/bus/acpi/devices/ only contains a folder called "acpi", which is linked to /sys/bus/acpi!! So you can CD inside of that forever:

luis@ordenata:~$ ls -l /sys/bus/acpi/devices/
total 0
lrwxrwxrwx 1 root root 0 2007-04-03 11:16 acpi -> ../../../devices/acpi

[Luis Alberto Pabón (copong)]

Sorry, I had a confusion, but there is something weird going on.

Correction:
/sys/bus/acpi/devices/acpi/ is linked to /sys/devices/acpi/

In /sys/devices/acpi there are two links (bus/ and subsystem/) that link to /sys/bus/acpi

So you can CD to:
/sys/devices/acpi/bus/devices/acpi/bus/devices/acpi/bus/devices/acpi/bus/devices/acpi .....

So there is some recursive linking going on here. I'm not sure whether this is related or not tho. I believe I used to go there to check what governors I had available.

[Sebastian Kügler (sebasje)]

Can you check what frequency lshal reports when it goes wrong?

[Luis Alberto Pabón (copong)]

Well, it goes wrong all the time, what I mean is that it always reports zero MHz (plugged or unplugged).

I cannot find anything that suggests processor freq in lshal's output, the processor related info is:
udi = '/org/freedesktop/Hal/devices/acpi_CPU0'
  info.udi = '/org/freedesktop/Hal/devices/acpi_CPU0' (string)
  linux.hotplug_type = 4 (0x4) (int)
  processor.can_throttle = true (bool)
  processor.number = 0 (0x0) (int)
  info.capabilities = {'processor'} (string list)
  info.category = 'processor' (string)
  info.product = 'Intel(R) Pentium(R) M processor 1.73GHz' (string)
  info.parent = '/org/freedesktop/Hal/devices/computer' (string)
  linux.acpi_type = 1 (0x1) (int)
  linux.acpi_path = '/proc/acpi/processor/CPU0' (string)

I have attached the full lshal output.

[Luis Alberto Pabón (copong)]

Screenshot showing the zero megahertz thingy

[hokal (h-kalweit)]

I can confirm Nablas problem. Have exactly the same problem on both notebooks (IBX X31 and Fujits/Siemens P7010) both Centrino after upgrade.
Is someone working on this ?

[Luis Alberto Pabón (copong)]

After several kde-guidance updates and one kernel update I still have the same problem.

luis@ordenata:~$ uname -a
Linux ordenata 2.6.20-14-generic #2 SMP Mon Apr 2 20:37:49 UTC 2007 i686 GNU/Linux

luis@ordenata:~$ apt-cache show kde-guidance
Version: 0.8.0-0ubuntu4

[Luis Alberto Pabón (copong)]

Still broken.

However, if, when already logged in, I restart the hal service (sudo /etc/dbus-1/event.d/20hal restart) it will work again. Well, I need to exit guidance-power-manager and exec it again because it doesn't seem able to connect back with hal or whatever it needs to.

It still works when logging out & in (no reboot).

It won't work after a reboot.

I attach another lshal output (after HAL restart).

I will reboot and get another lshal dump and attach it here, since the previous lshal output I uploaded was with a different kernel.

[Luis Alberto Pabón (copong)]

lshal output before restarting the hal service.

I have diffed both, and the most remarkable differences are:
> info.capabilities = {'cpufreq_control'} (string list)
10c11
< info.interfaces = {'org.freedesktop.Hal.Device.SystemPowerManagement'} (string list)
---
> info.interfaces = {'org.freedesktop.Hal.Device.SystemPowerManagement', 'org.freedesktop.Hal.Device.CPUFreq'} (string list)

[Pascal d'Hermilly (pascal-tipisoft)]

I dont understand that this bug has low priority. It should _at_least_ be medium.
This is a very obvious bug that doesn't speak well for linux's hardware troubles!
At least there should be made a workaround where the CPU frequency is hidden if it's 0mhz.

[Mark Reitblatt (mark-reitblatt)]

I rated it as low because it only affects a small percentage of Ubuntu users, seems to have no serious side effects, and is easily worked around. It doesn't appear to be a HW bug since others seem to be reporting that power management is working normally, it is just this one applet that is misbehaving. If you really want this to be taken care of, I suggest filing a bug upstream (http://bugs.kde.org/) and linking it to this bug report. They are likely to have more resources available to focus on KDE-specific bugs.

[Luis Alberto Pabón (copong)]

I disagree, Mark. This is a HAL, not a KDE issue. The applet is NOT misbehaving, it is acting properly. It is HAL itself who fails to detect CPU capabilities, as per my two last posts - restarting the HAL service after boot has finished will workaround the issue. Only then will HAL report proper CPU capabilities.

This is not a KDE issue. A similar applet in GNOME will have the same problem.

[Luis Alberto Pabón (copong)]

HAL fails to report CPU capabilities unless restarted.

[Mark Reitblatt (mark-reitblatt)]

Please include in file attachments the following information:
      The make and model of the device (as much as you know)
      The output from the uname -a > uname-a.log command
      The output from the lspci -vvn > lspci-vvn.log command
      The output from the lspci -vv > lscpi-vv.log command
      The output from the dmesg > dmesg.log command
      The output of cat /proc/version > proc_version.log command

[Pascal d'Hermilly (pascal-tipisoft)]

Make and model:
Toshiba Satellite m100-149

$ uname -a
Linux pascal-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

$ cat /proc/version
Linux version 2.6.20-15-generic (root@palmer) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Apr 15 07:36:31 UTC 2007

[Mark Reitblatt (mark-reitblatt)]

Please don't change the status of assigned bugs.

[Luis Alberto Pabón (copong)]

Sony VAIO FS285M (Centrino, Pentium M 1.73GHz chipset. Files follow.

[Luis Alberto Pabón (copong)]

dmesg

[Luis Alberto Pabón (copong)]

lspci -vv

[Luis Alberto Pabón (copong)]

lspci -vvn

[Luis Alberto Pabón (copong)]

/proc/version

[Luis Alberto Pabón (copong)]

uname -a

[Pascal d'Hermilly (pascal-tipisoft)]

I'm sorry Mark. I meant no offense.
I thought I was supposed to do that when I had uploaded the requested information.
Now I know for future reference.

[Mark Reitblatt (mark-reitblatt)]

It's alright. It's just that I assign the bug to myself when I set
"Needs Info" so that I can go back and quickly find it. But, I'm not
the guy who will actually be able to fix it, so if it is set to
"confirmed" and still assigned to me, then someone might get confused
and overlook the bug.

On 4/19/07, Pascal d'Hermilly <email address hidden> wrote:
> I'm sorry Mark. I meant no offense.
> I thought I was supposed to do that when I had uploaded the requested information.
> Now I know for future reference.
>
> --
> Doesn't detect CPU frequency
> https://bugs.launchpad.net/bugs/89750
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Anybody who tells me I can't use a program because it's not open
source, go suck on rms. I'm not interested. 99% of that I run tends to
be open source, but that's _my_ choice, dammit.

-- Linus Torvalds

[Benno Schulenberg (bennoschulenberg)]

Pascal's Celeron M 420 cpu does not support frequency scaling (see http://en.wikipedia.org/wiki/Intel_Core#Derivatives), so it should not show the Frequency bar at all, in my opinion. Attached patch achieves that for me on the same cpu.

For Nabla a workaround could maybe be found in automatically restarting HAL at some point, or starting it later in the boot process?

[Luis Alberto Pabón (copong)]

I have done what Benno (thanks Benno :)) suggested and it oubviously workarounded the problem (adding 20hal restart on rc.local).

Just for the record, I've found that acppi-support is run almost at the end of the boot process (S99acpi-support), whereas dbus is loaded at the beginning (S12dbus), might this be related? acpid is loaded pretty much at the beginning (S10acpid). Can it be that the system doesn't have speedstep capabilities until acpi-support is loaded, so hal can't find out about it when it loads?

[Pascal d'Hermilly (pascal-tipisoft)]

Benno. ok, I didn't know that, but I agree that the frequency bar should not be shown at all then.

[tomaszr (tomasz-rosinski)]

In my opinion Ubuntu Feisty Fawn giving more problem than Edgy Eft. I think that is too fast public version. eh ... :(

[Benno Schulenberg (bennoschulenberg)]

Any more information you can give, tomasz? Is your problem like Nabla's or like Pascal's? Or other still?

[tomaszr (tomasz-rosinski)]

@Benno, CPUFREQ scaling on my CPU is'nt work. I Have Celeron 370 1500MHz on Acer TravelMate. (8 steps) but not work. Problem subscribed on https://bugs.launchpad.net/ubuntu/+bug/110504

[Mark Thompson (mjthfx)]

Do you need anymore information regarding this bug? It used to work fine for me in Edgy but since upgrading to Feisty, the guidance power manager does not report the frequency for my dual core Dell LAtitude D620 Notebook.

Attached are my output files as requested above.

[Luis Alberto Pabón (copong)]

Just as a quick note: I still have the problem, however, I workaround it as
I described on my last post so it kind of works for me... other users that
do not know how to implement the workaround will be screwed though.

On 29/05/07, Mark Thompson <email address hidden> wrote:
>
> Do you need anymore information regarding this bug? It used to work fine
> for me in Edgy but since upgrading to Feisty, the guidance power manager
> does not report the frequency for my dual core Dell LAtitude D620
> Notebook.
>
> Attached are my output files as requested above.
>
>
> ** Attachment added: "dmesg.log"
> http://librarian.launchpad.net/7868123/dmesg.log
>
> --
> Doesn't detect CPU frequency
> https://bugs.launchpad.net/bugs/89750
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Luis Pabón

[Fernando Díaz (fernio)]

I have a notebook with a Celeron M 1.5 and had this same problem. It went away after adding "p4-clockmod" (without quotes) to /etc/modules. It even added the ability to change the CPU governor (showed as CPU policy). Hope this helps.

[sk0rp10 (matteo-andreozzi)]

Still broken in Gutsy

[Luis Alberto Pabón (copong)]

sk0rp10, does restarting HAL and restarting the applet after the system is fully booted workaround the problem for you?

[sk0rp10 (matteo-andreozzi)]

Yes , it works

[sk0rp10 (matteo-andreozzi)]

Yes , it works by restarting both Hal and the applet

[getriebesand (getriebesand)]

I have upgraded my Edgy to Feisty and the upgrade tool is crashed at the end. Power Manager shows 0 MHz and Adept says powernowd and powersaved are not installed but in /etc/init.d the startup scripts exists and also in rc2.d

The workaround to restart hal with rc.local works fine.

Now I have installed powernowd and powersaved and purged they again.

Now the work around doesnt' work anymore. (because powernowd is not installed)
I have reinstalled powernowd, removed the work around in rc.local and all works fine

I think powernowd was not upgraded or something goes wrong during the upgrade process.