This is correct. The CPU has been detected correctly.
It looks like the VM guest has no access to the HW counters.
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
Events were actively counted for 2669610 nanoseconds.
you enable PMU for the guest.
Post by dhara buch
What is the solution?
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
I am using i7 core processor. When I executed ophelp -r, the
displayed CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Afterwards, when I execute opcontrol --vmlinux=(uncompressed
form of vmlinuz) command, the CPU type gets changed to 'CPU with timer
The problem would be in uncompressed file? I am also not much
clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
There are two modes oprofile knows, let's call them "opcontrol-mode"
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
Hope it helps.
On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <
I have installed Oprofile-0.9.9 on Ubuntu 15.10.
I try to init oprofile with'
opcontrol --init command, which requires
uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the present vmlinuz
with extract-vmlinux script. The file gts uncompressed,but when I init
opcontrol with this uncompressed
file, my CPU
type gets wrongly
identified. Hence, although the hardware events
are supported by the processor, 'timer' mode gets set and event monitoring
doesn't become possible.
You can test the CPU identification by running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is pretty old, it
might not support
the newer processors. Consider using the latest
OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based
profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1)
should serve you
I would be thankful if anybody can guide me to
solve this problem.