Wrong CPU clock speed reported on RaspberryPi since Linux Kernel v3.8

[GoogleCodeExporter]

What steps will reproduce the problem?
$ inxi -C

What is the expected output? What do you see instead?
Actual:
CPU:       Single core ARMv6-compatible rev 7 (v6l) (-UP-) (ARM) clocked at 2 
MHz 
Expected:
Along "... at 700 MHz"

What version of the product are you using? On what operating system?
inxi 2.1.19-00 (2014-04-06)

Please paste your inxi output below.
(see above)

Please paste your 'cat /proc/cpuinfo' output below.
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 2.00
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000f
Serial          : 000000005c17bbda

please paste your 'cat /proc/meminfo' output below.
(not related)

please paste your 'sensors' output below.
(not related)

further information:
Kernel version: Linux rpi 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 
armv6l GNU/Linux

I'm aware that you calculate the MHz based on the BogoMIPS, but apparently 
there has been some change in the way BogoMIPS for that CPU are calculated. It 
no longer equals the actual MHz but is derived from the system tick value.

I don't know how to fix either.

Original issue reported on code.google.com by krf...@gmail.com on 8 Apr 2014 at 10:32

[GoogleCodeExporter]

Well, there's 'cpufreq-info', which you could try to use as a fallback:

$ cpufreq-info                                                                  

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: BCM2835 CPUFreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 355 us.
  hardware limits: 700 MHz - 950 MHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 700 MHz and 950 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 700 MHz.

Original comment by krf...@gmail.com on 8 Apr 2014 at 10:40

[GoogleCodeExporter]

I try to avoid non standard programs to get data into inxi, at all costs.

I get in Debian, 

which cpufreq-info
/usr/bin/cpufreq-info
dpkg -S /usr/bin/cpufreq-info
cpufrequtils: /usr/bin/cpufreq-info

which is not a current recommends/dependency of inxi.

I can add a test I guess if ARM and if cpufreq-info... or something but I don't 
want to add a recommends to inxi to fix what is truly a bug in ARM kernel data. 
A bogomip is a fake unit that shows how many times the kernel can do a certain 
operation, so the result of 2.0 is clearly wrong, and should not exist, ie, 
it's a bug.

I don't think it's a good idea to use inxi to fix bugs in general, though I 
will do it at times when it seems like it will never get fixed upstream.

Original comment by inxi-...@techpatterns.com on 8 Apr 2014 at 10:49

• Changed state: Accepted

[GoogleCodeExporter]

I could conceivably create a fall back function to grab the data if the value 
for cpu speed(s) is wrong or null and if cpufreq-info is present, but these 
kinds of fixes are dangerous because it bloats the inxi code in a way that is 
not good.

Original comment by inxi-...@techpatterns.com on 8 Apr 2014 at 10:52

[GoogleCodeExporter]

Ah, I forgot to link a discussion from kernel.org:
http://www.spinics.net/lists/sparclinux/msg08550.html

Citing from there "Absolutely no interpretation of the bogomips value should 
ever be
made.". So I don't think you can consider BogoMIPS == 2 being a bug.

Original comment by krf...@gmail.com on 8 Apr 2014 at 10:57

[GoogleCodeExporter]

For reference.

This works for non-root users as well:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
700000

Original comment by krf...@gmail.com on 8 Apr 2014 at 11:50

[GoogleCodeExporter]

inxi 2.1.20 fixes this with the /sys method, but that only works for single 
core arm cpus, for  multicore, I need to see the /proc/cpuinfo data so I can 
test with it.

I can't make people change, the problem of course is that cpuinfo should simply 
provide the arm cpu speed, and that failing is a bug, always has been, which is 
why inxi was forced to use bogomips, a hack, but the original bug remains, no 
cpu frequency speed, data that is clearly readily available elsewhere so why is 
it not in cpuinfo?

The hack is to use your fix if and only if speed is null, or speed is less than 
50 (I picked 50 at random, basically no cpu that exists is that slow today), 
then use the hack, if it's not null as result, great, that's that, if it is, 
leave null, with error message re arm.

Original comment by inxi-...@techpatterns.com on 9 Apr 2014 at 12:52

[GoogleCodeExporter]

Note that this fix only works for single core arm, I have no data samples of 
the new cpuinfo data for multicore arm, so no way to know what it is doing.

I think in general for arm, bug reports should be sent to kernel or whoever is 
in charge of arm not showing cpu frequency/speed in /proc/cpuinfo, that's the 
actual bug.

Original comment by inxi-...@techpatterns.com on 9 Apr 2014 at 12:54

• Changed state: Started

[GoogleCodeExporter]

http://raspberrypi.stackexchange.com/questions/1219/how-do-i-determine-the-curre
nt-mhz

1 Look at the /proc/cpuinfo - No MHz listed, does have BogoMIPS at 697, while 
CPU speed is set at 900. 
2 The sysstat package - returns 0.00 MHz.
3 cpufreq-info: no or unknown cpufreq driver is active on this CPU

so apparently cpufreq-info is also not a reliable solution, so that removes 
that as an option in any case.

Original comment by inxi-...@techpatterns.com on 9 Apr 2014 at 2:32

[GoogleCodeExporter]

A few tweaks to 2.1.20, I believe now it may handle the same corruption in 
multicore arm cpus where it shows fake low bogomip data, and no cpu frequency, 
now the actual cpu data generator also uses the /sys data if cpu speed is null, 
for each core.

So that should largely fix it, I think, though I am sure it will break again 
since clearly someone in the chain has no respect for the output that goes to 
/proc/cpuinfo.

As noted, the real bug is failing to report cpu frequency in cpuinfo, the 
second that data is back none of these hacks will activate in the first place.

I'm leaving unhandled for now null cpu speed data.

Original comment by inxi-...@techpatterns.com on 9 Apr 2014 at 7:14

[GoogleCodeExporter]

CPU~Single core ARMv6-compatible rev 7 (v6l) (-UP-) clocked at 700 MHz 
Kernel~3.10.25+ armv6l Up~37 days Mem~220.2/485.3MB HDD~1500.3GB(36.2% used) 
Procs~121 Client~Shell inxi~2.1.20

Seems to work, so I'm closing this issue.

Original comment by inxi-...@techpatterns.com on 9 Apr 2014 at 6:41

• Changed state: Verified