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.

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.

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.

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.

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.

For reference.

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

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.

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.

http://raspberrypi.stackexchange.com/questions/1219/how-do-i-determine-the-current-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.

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.

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.