The vicious cpufreq widget uses
/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq, which seems to
be gone in 3.10, and the new cpuinfo_cur_freq is root:root 0400 :/

Cf. e.g. https://lkml.org/lkml/2013/5/28/320

Cheers,
gregor


- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages awesome-extra depends on:
ii  curl  7.31.0-2

Versions of packages awesome-extra recommends:
ii  awesome  3.4.15-1+b1

awesome-extra suggests no packages.

- -- no debconf information

- -- debsums errors found:
sh: /usr/sbin/dpkg-divert: No such file or directory
iQIcBAEBCAAGBQJR9SAoAAoJELs6aAGGSaoGI24P/0+YIKzmN0nLdQYrpeNa2TZW
cWp/R0AXYoY781R3xJ/QwcQjJrXgKdn/knimJiS+Mkhj1KVsJyS4mCwVFp9nJhlw
wrtQIH+KI/fWUGl/TuLlOsIjM/f43yXa/mWWZVdQNbPlieLbVVbu2Ch7BC/g2/z8
fZt6J47Js3TXIcaBSX+7L0vU3Pv3Rdy4ocoeWF/7I5LnQDbfA2yUy1PkMxVN0qzI
o0gDCEOTv0O3vy0BykU993AiF+fL6Pb8gXPx9IttXAXjZuYZDjFGLmZ/W5+af6Op
8DYYgrCkZu/rO1aIFYialq2IhwlVelQlwwzcl1Atg1d6fgd+PTcGxiB5+bKPyyFA
+p5n5noKhuo5jNeS1bqxzeyTf9HDWVA8lSgWNMjIrSvkUFA1w9j1w0FWQQPbFZF/
wobdkl4ANQpfN9lYlHRU7t2h7GMcUnmnu1q92Q82tg1HGfssfHDKZvbnUdasLjhv
wCTY3Zl1G/GXhgI84FPExCEwStAobX6to8nifWkAQGMitoqHYcSRqvSabddAqeMN
wvqIOn0t7kVP11yDV4ayBgUcDSt5ysTJ9ALenbbQWbG5tujdCWT+0hbZIEtr7BTg
wnY9hj8qmEIaCPvC4doG//fFI2AJKiVsoxO3gZMY4KtQR9IRlgp20i0GZdIDxsC1
ydD7xxtFhDRa3F+KNAWo
=fSUE
-----END PGP SIGNATURE-----

Concerning root:root 0400 ownership, the workaround I would suggest would be
to install the 'sysfsutils' package and then to make entries in
/etc/sysfs.conf to manually set file mode and ownership, such as:

--------------------
mode  devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq = 0440
mode  devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq = 0440
...
owner devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq = root:adm
owner devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq = root:adm
...
--------------------

Another confusing thing is that I'm using Debian's 3.10 kernel, but for some
reason scaling_cur_freq and cpuinfo_cur_freq both exist on my system.  (Not
sure why that is.)

   # uname -r
   3.10-1-amd64

   # ls -1  /sys/devices/system/cpu/cpu0/cpufreq/
   affected_cpus
   bios_limit
   cpuinfo_cur_freq
   cpuinfo_max_freq
   cpuinfo_min_freq
   cpuinfo_transition_latency
   related_cpus
   scaling_available_frequencies
   scaling_available_governors
   scaling_cur_freq
   scaling_driver
   scaling_governor
   scaling_max_freq
   scaling_min_freq
   scaling_setspeed
   stats

Oh, nice, I didn't know that.

It depends on the scaling_driver; I'm using (not by my own decision,
but hey :)) intel_pstate.

I had a quick look into the kernel sources today, and depending on
the driver's "properties" cpuinfo_cur_freq and/or scaling_cur_freq
are created, at least that was my conclusion.


Cheers,
gregor

I didn't either until I tried to use 'cpufreq-set' from the 'cpufrequtils'
package as a normal user, and then found that I didn't have permission to
manually change the CPU frequency due to the permission/ownership on these
files.

Normally I use sysfsutils for setting battery charge thresholds with the
tp_smapi module, and /etc/sysfs.conf contains comments specific to changing
/sys file mode+ownership, so that's how I found out it could do this.

This makes sense after I read the 'help' in a 'make menuconfig' on the Linux
kernel source.

Okay.  The output of these two 'files' (pointers to kernel memory) output the
same information:

  # cat cpuinfo_cur_freq scaling_cur_freq
  800000
  800000

I currently don't know if it's possible to make a [soft|hard]link within /sys,
but if that were possible that would be a way around the lack of the
scaling_cur_freq filename.

If nothing else this should be possible via a custom Linux kernel module.
I've experimented with doing this, which is explained in "Linux Device
Drivers":

https://lwn.net/Kernel/LDD3/

which is another book I'm hoping to get back to reading...



P.S. I've subscribed to this bug (manually), so I don't need to be CCed.
Cheers