#29 cpufreqd-2.3.4 doesn't see CPU sensors via lm_sensors3


cpufreqd-2.3.4 doesn't see my CPU temperature sensors via sensors-plugin.
(I have lm_sensors-3 installed.)
sensors-plugin parses config file entries correctly, but it seems to me, that
lm_sensors give no sensors for my chip. But if I type "sensors -u", I get the
"Core0 Temp:
temp1_input: 45

Core1 Temp:
temp3_input: -49"

So I can clearly see, that there ARE temperature sensors on my chip
(temp1_input), but cpufreqd ignores the "sensor=temp1_input:61-100", for
example, in my cpufreqd.conf file.

Reproducible: Always

Steps to Reproduce:
1. emerge sys-apps/lm_sensors-3.1.1 sys-power/cpufreqd-2.3.4-r1
2. type "sensors -u" and see the sensors information.
3. start cpufreqd and see the /va/log/messages file to see the "Discarding"
messages from cpufreqd.

Actual Results:
Cpufreqd ignores the temperature sensors.

Expected Results:
Cpufrqd shouldn't ignore temperature sensors


  • v_2e

    v_2e - 2009-12-24

    Thanks for such a quick replying! :)
    I'd like to check out the latest trunk, but unfortunately I cannot use autotools (autoconf, automake, ...) - I just don't know how to use them. I've tried to simply run autoconf, autoheader, automake, but some errors occured and Makefile hadn't been created at all.
    If there is a quite simple way to build this packages, I will test the latest version with pleasure! :)

    By the way, I use GGL (Gentoo GNU/Linux) and thus every program is usually built by Gentoo Portage system automatically (it runs every necessary program to build the package without asking). And also Gentoo developers team usually provide some patches to make the resulting program work fine in GGL. I have seen few patches for Cpufreqd there too. I'm not completely sure about what they actually do, but they seem to fix some CPU sensors detecting bugs and also make Cpufreqd work with new versions of lm_sensors. Still, I'm not a programmer at all and I cannot tell you for sure the purposes of those patches, that is why I'd like to suggest you to look through them as the master developer - maybe it will be useful for faster development and bug fixing.

    P.S. If there is a straightforward way to build Cpufreqd from trunk - please let me know. I'm looking forward to your reply. :)

  • Mattia Dongili

    Mattia Dongili - 2009-12-24

    Well, you have two choices here then:
    1. Be patient until I release cpufreqd wit those changes (which should happen very soon)
    2. Contact the gentoo guys and ask them to include that patch as I am not familiar with portage


  • v_2e

    v_2e - 2009-12-26

    I have figured out how to use GNU autotools and successfully built Cpufreqd from trunk. I have also met this problem on my way:

    However, it did not help. Cpufreqd still gives error messages like this:

    cpufreqd: sensor_parse : feature "temp1_input" does not exist, try 'sensors -u' to see a full list of available feature names.
    cpufreqd: plugin_handle_keyword : sensors_plugin is unable to parse this value "temp1_input:53-60". Discarded
    cpufreqd: parse_config_rule : WARNING! skipping config option "sensor"

    And this is what 'sensors -u' gives:

    Adapter: PCI adapter
    Core0 Temp:
    temp1_input: 35.00
    Core1 Temp:
    temp3_input: -49.00

  • v_2e

    v_2e - 2010-01-10

    Hello again!
    Good news here!
    Looks like one of kind GGL users has submitted a working patch to fix this problem. Here is a link to it:

    You may also be interested in some comments. Here they are:

    I believe it would be good if you review this patch and maybe accept it as a working solution to fix this bug "upstream", because... you know... not everyone in this world uses GGL. :) Other people may be (and I am sure they will be) interested in this problem being fixed.

    And thanks for responding!

  • Mattia Dongili

    Mattia Dongili - 2010-01-10

    err... any chance that the patch can be diff'ed against my git repository? Most of this code is already included in cpufreqd, not a single hunk succeeded:
    mattia@caligola:~/devel/cpufreqd> patch -p0 --dry-run < /tmp/patch
    patching file src/cpufreqd_sensors.c
    Reversed (or previously applied) patch detected! Assume -R? [n]
    Apply anyway? [n] y
    Hunk #1 FAILED at 23.
    Hunk #2 FAILED at 133.
    Hunk #3 FAILED at 164.
    Hunk #4 FAILED at 214.
    4 out of 4 hunks FAILED -- saving rejects to file src/cpufreqd_sensors.c.rej

    actually it looks very much like what I have in my source tree.
    Did you actually build the code in my repository back then when I asked?

    thanks for informing me of the patch and the status of this bug


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks