Looking back in time, this may be related to Scott's post from a short while back, though he encountered the udelay issue on 3.2:


On Thu, May 16, 2013 at 12:01 PM, Akram Hameed <akramh@aq1systems.com> wrote:
Howdy folks,

Have set my Waterstorm to 800MHz using the typical u-boot envvar, and 'cpufreq-info' reports the following which is always nice to know:

root@overo:~# 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: omap
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 300 us.
  hardware limits: 300 MHz - 1000 MHz
  available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
  available cpufreq governors: conservative, ondemand, powersave, userspace, performance
  current policy: frequency should be within 300 MHz and 1000 MHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 800 MHz (asserted by call to hardware).
  cpufreq stats: 300 MHz:0.00%, 600 MHz:0.00%, 800 MHz:100.00%, 1000 MHz:0.00%

But looking in /proc/cpuinfo, I see that BogoMIPS looks like it hasn't been recalculated from (I suppose) a number that derived from a 600MHz clocking (dmesg confirms it started up in that freq...).

root@overo:~# cat /proc/cpuinfo
Processor   : ARMv7 Processor rev 2 (v7l)
BogoMIPS    : 597.64
Features    : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x3
CPU part    : 0xc08
CPU revision    : 2

Has anyone else encountered this, and if so, what effect has it had on your system? Surely a dodgy bogomips is going to cause weird issues with udelay and so on?