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

[v_2e]

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
message:
"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

[Mattia Dongili]

Could you please try the latest version from the git repository at: git://git.kamineko.org/cpufreqd.git
This commit should fix it: http://git.kamineko.org/cgi-bin/gitweb.cgi?p=cpufreqd.git;a=commitdiff;h=7b979d9b56de4ef9477b02e378212cc71daffcf6

thanks

[v_2e]

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]

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

Cheers

[v_2e]

I have figured out how to use GNU autotools and successfully built Cpufreqd from trunk. I have also met this problem on my way:
http://old.nabble.com/nested----with-whitespace-in-misc-description-leads-to-_m4_text_wrap_word-errors-td25944510.html

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:

k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp:
temp1_input: 35.00
Core1 Temp:
temp3_input: -49.00

[v_2e]

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:
https://bugs.gentoo.org/attachment.cgi?id=215896&action=view

You may also be interested in some comments. Here they are:
http://bugs.gentoo.org/show_bug.cgi?id=295044

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]

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