<?php require("../start_page.php"); start_page("faq/", "OProfile FAQ"); ?>
<h3>How do I build OProfile ?</h3>
For 2.4 kernels, you must have the kernel source available for the kernel
you want to run OProfile under. Do <tt>./configure --with-linux=/path/to/kernel/source</tt>
then <tt>make install</tt>. This option is no longer supported with OProfile 0.9.8
For 2.6 or higher kernels, ensure that the kernel has been configured to include OProfile, either
built into the kernel or as a module. Next, do <tt>./configure --with-kernel-support</tt>.
As of OProfile 0.9.8, kernel support is assumed, and the <tt>--with-kernel-support</tt>
option is no longer needed nor available.
<h3>Where can I get the required libraries ?</h3>
Most required runtime libraries should already be installed on your system.
For building OProfile, you may need to install additional devel packages --
for example, the binutils development package, which provides libiberty
and others. On Debian, this package is not installed by default, and
is named "binutils-dev".
<h3>How do I get started ?</h3>
Read <?php rlink("doc/overview.html#getting-started", "Getting started") ?>.
<h3>How do I reset the profiling data ?</h3>
For legacy OProfile (i.e., <tt>opcontrol</tt>-based profiling), use <tt>opcontrol --reset</tt>,
or you can save the session under a name with <tt>opcontrol --save <sessionname></tt>.
When using <tt>operf</tt> for profiling, a new profiling session will cause the current
profile data (stored in <tt><cur-dir>/oprofile_data/samples/current</tt>) to be
renamed from <tt>current</tt> to <tt>previous</tt>, so there is usually no need to manually
delete old profile data. However, a manual deletion can be accomplished by simply
doing <tt>rm -rf <cur-dir>/oprofile_data/samples/current</tt>.
<h3>I get "error: no sample files found: profile specification too strict ?"</h3>
If using <tt>operf</tt>, make sure you run OProfile post-processing tools (e.g., <tt>opreport, opannotate</tt>)
from the directory where you collected the profile. Alternatively, you can specify the
location of sample data using the <tt>--session-dir</tt> option.
<p>Incorrect specification of the image name (i.e., app name) when invoking post-processing tools
is a common cause for this error message. If you used <tt>operf</tt> to profile a single application,
there is no need to append the image name at the end of your invocation since samples are collected
only for the given application.
For other possible causes for this error message, read <?php rlink("doc/results.html#no-results", "What to do when you don't get any results") ?>.
<h3>Can OProfile profile the kernel too ?</h3>
Yes, if you pass the <tt>--vmlinux</tt> option when profiling, OProfile will profile the kernel and
all kernel modules, and the post-processing tools will show kernel symbols for which samples
were taken. In order for post-processing tools to show symbol info for kernel modules, you
must pass the <tt>--image-path</tt> option; for example, <tt>opreport --symbols /lib/modules/`uname -r`</tt>.
<h3>I don't have a vmlinux file, but I want to profile the kernel anyway !</h3>
If using <tt>operf</tt>, all kernel samples are automatically attributed to a
"no-vmlinux" pseudo-symbol, unless the <tt>--vmlinux</tt> option is used.
If profiling with legacy <tt>opcontrol</tt>, use <tt>opcontrol --no-vmlinux</tt> if no
vmlinux file is available. Then
this script to list the samples</a>.
<h3>Why do the profile tools fail to open the vmlinux kernel image ?</h3>
Probably because you have accidentally specified the vmlinu<em>z</em> not
vmlinu<em>x</em> file. If you don't have a vmlinux file, most Linux distributions provide
a kernel debuginfo package that includes it. Otherwise, you need to recompile your kernel from source.
If you're not interested in kernel samples, then don't use the <tt>--vmlinux</tt> option
(and for legacy profiling, use <tt>opcontrol --no-vmlinux</tt>).
<h3>Why is OProfile ignoring me when I try to change the events to profile ?</h3>
When using legacy <tt>opcontrol</tt>, the <tt>oprofiled</tt> daemon must be
restarted in order to use newly-specified events and other new profiling parameters.
To restart the daemon, you must use <tt>--shutdown</tt>, not
<tt>--stop</tt>, as the latter does <em>not</em> restart the daemon.
Note that old profiling data is still kept; only <tt>--reset</tt> or
<tt>--save</tt> will clear the default sample data directory.
<h3>But Red Hat doesn't ship a <tt>vmlinux</tt></h3>
Actually they do, but it's not installed by default; it's
included the <tt>kernel-debuginfo</tt> package.
<h3>Why is OProfile in timer mode on x86? I have performance counters...</h3>
Some 2.6+ kernels disable the local APIC by default. You can try
enabling the local APIC (if you do indeed have one) by booting with the
<tt>lapic</tt> boot option.
<h3>Why does OProfile fail with "can't get RTC I/O ports" ?</h3>
On some systems running with pre-2.6 kernels, only RTC mode profiling is available, as described
in the documentation. If RTC mode is used, you must <i>not</i> use a kernel
with the RTC driver built-in (that is, <tt>CONFIG_RTC</tt> must not be set to
<tt>y</tt>). Otherwise, OProfile cannot acquire the RTC hardware for its own
use, and you will get this error message. If you have compiled the kernel's
RTC driver as a module, you must unload it before using OProfile.
<h3>Can I get a summary of the whole system ?</h3>
Assuming you collected a system-wide profile with either <tt>opcontrol</tt> or <tt>operf --system-wide</tt>, try
<div class="computeroutput">opreport -l
<h3>Can I get top-like output from OProfile ?</h3>
Sure ! Try something like this :
<div class="computeroutput">watch --interval=1 "opcontrol --dump && opreport -l 2>/dev/null | head -30 ; opcontrol --reset"
for a symbol-based system-wide summary, or
<div class="computeroutput">watch --interval=1 "opcontrol --dump && opreport -l /boot/2.6.0/vmlinux | head -30 ; opcontrol --reset"
for an image-specific summary.
<h3>Oprofile and laptops</h3>
Users have reported a few problems using OProfile on laptops.
Many laptops do not have performance counter hardware; in this case OProfile
falls back to RTC/timer mode (read the <? rlink("docs/", "documentation"); ?> for
Users report that power management is not compatible with OProfile
on some laptops. Enabling power management is likely
to hang your box if you are using the performance counters. This
does not apply if you're using a 2.6 or higher kernel.
<h3>What sort of overhead does OProfile have ?</h3>
It's dependent upon how you set up the counters, but it's typically
lost in the noise (1-3%). <? rlink("performance/", "This graph gives typical examples."); ?>
<h3>What architectures are supported by OProfile ?</h3>
OProfile ports for IA-64, AMD64, ARM, Alpha, PA-RISC, sparc64, s390, and ppc64
are all in various stages of support, mostly only on 2.6 or higher kernels. Older processor
models or defunct architectures may only be supported with the legacy (i.e., <tt>opcontrol</tt>)
profiler, while newer processors/architectures may only be supported with <tt>operf</tt>.
<h3>Can OProfile collect call graphs like <tt>gprof</tt>?</h3>
Yes, starting with OProfile 0.8 and kernel version 2.6, callgraph support
is available on many (but not all) architectures, such as x86, ARM, and ppc/ppc64.
<h3>What about the "security hole" <a
This "problem" only occurs if you actively, and mistakenly, configure
access to OProfile via sudo. OProfile uses shell scripts which have not
been audited (nor is it likely to happen) for use through the broken
sudo facility (anything that lets you alter root's path arbitrarily
counts as horribly broken). <em>Do not use sudo</em>!
<h3><a id="binutilsbug"/>I get an error from the post-profiling tools referring here?</h3>
Some binutils versions (at least 2.12) are mis-compiled by gcc 2.95.3,
which causes a crash or hang in <tt>opreport</tt> and the other tools.
See the OProfile <a href="http://sourceforge.net/tracker/index.php?func=detail&aid=717720&group_id=16191&atid=116191"
title="bug 717720 - gcc 2.95.3 post profile tools crash or hangs">bug report</a>
for a patch to work around the problem. This is reported to be a
problem with Slackware 8.1, and probably some other older Linux
<h3>Using the 2.4 kernel module, I get "Failed to open hash map device: Operation not permitted"?</h3>
This is an intermittent problem that was never completely resolved. The device
file <tt>/var/lib/oprofile/hashmapdev/</tt> is failing the <tt>capable(CAP_SYS_PTRACE)</tt>
test. The simplest workaround is to remove <em>both</em> of these tests in the source
(<tt>oprofile.c</tt>), recompile and reinstall OProfile, then run <tt>opcontrol --deinit</tt>
and start again.
<h3>SUSE kernel, I get: "May 8 11:05:14 mynode kernel: Unable to handle kernel paging request at virtual address ffffe030"</h3>
This occurs with older SUSE UP kernel when you compile your
kernel with CONFIG_X86_LOCAL_APIC. By default, these kernels do
not up the local apic. You must force local apic initialization
by booting with the kernel command line parameter <tt>apic</tt>.
OProfile can't work with VMware when using performance counter interface.
A workaround is to use RTC mode (2.4 kernel) or timer interrupt mode (2.6+
<h3>What is the meaning of "cpu_type 'unset' is not valid"</h3>
This error can occur when using legacy <tt>opcontrol</tt> for profiling. Generally this means your kernel supports your hardware, but user space tools are not up to date. You should try to upgrade. You can check if your hardware is supported by looking at <tt>/dev/oprofile/cpu_type</tt>.
<h3>What are the [vdso] messages I sometimes see from opreport?</h3>
Occasionally, opreport displays messages like the following:
<div class="computeroutput">warning: [vdso] (tgid:1664 range:0xf732a000-0xf732b000) could not be found</div>
If you get this error message, you can safely ignore it. It just indicates
temporary memory allocations from the kernel where it loaded some executable
code into memory. The fact you are seeing those messages indicates some
samples were taken when that code was running, but now, at post-processing
time, 'opreport' cannot find the VDSO anymore. VDSO is virtual dynamic
shared object. From http://kernelnewbies.org/KernelGlossary, it's "a
kernel-provided shared library that helps userspace perform a few kernel
actions without the overhead of a system call, as well as automatically
choosing the most efficient syscall mechanism. Also called the "vsyscall page".
<h3>What do I do when configure fails with "syntax error near unexpeced token QT"?</h3>
<p>Under certain conditions, you may see the following oprofile configure error:</p>
<div class="computeroutput">./configure: line 20300: syntax error near unexpected token `QT,'
./configure: line 20300: ` PKG_CHECK_MODULES(QT, Qt3Support QtGui QtCore ,,'
<p>In general, there are multiple possible causes for this error, including the pkgconfig package not being installed.
But you can also get this error if you have installed aclocal in a location other than /usr.
Here's a scenario that can get you into trouble.</p>
<blockquote>You have installed the automake package (which includes aclocal) from your
distro, along with other packages that have m4 files (such as pkgconfig).
Then, for one reason or another, you install another version of aclocal via a local build/install. Unless
you specify differently with the '--prefix' option, this other version of aclocal will be installed at
/usr/local/bin/aclocal, which typically will be found in your PATH ahead of the /usr/bin/aclocal.
Then, when running oprofile's autogen.sh, aclocal is called and it looks for a dirlist file in
<aclocal-install-dir>/share/aclocal. The distro-supplied aclocal includes a dirlist file,
which tells aclocal of locations to look for m4 files (such as the pkg.m4 file). But your
version of aclocal in /usr/local does <em>not</em> have this dirlist file automatically, so
your aclocal is not able to find pkg.m4 and fails with the above syntax error.</blockquote>
<p>There are two ways to eliminate this error: 1) copy the /usr/share/aclocal/dirlist file to
your other aclocal installation, and edit the file to point back to '/usr/share/aclocal' (RECOMMENDED); or
2) add "-I /usr/share/aclocal" to the invocation of aclocal in oprofile's autogen.sh either by
editing the autogen.s file or by invoking autogen.sh as follows:
<div class="computeroutput">ACLOCAL='aclocal -I /usr/share/aclocal' ./autogen.sh
<h3>operf issues on older kernels</h3>
The <tt>operf</tt> tool depends on a kernel feature called Linux Kernel Performance Events Subsystem
(aka "perf_events"). This feature was initially included with the 2.6.31 kernel, but over the next
several versions, it evolved rapidly to fix bugs and add new capabilities. Several Linux distributions
were released using kernels based on 2.6.31 or 2.6.32 which were heavily patched with perf_events
fixes. However, not all critical fixes made their way into these early perf_events-enabled
Linux distributions. For example, the <tt>operf</tt> tool from the official 0.9.8 release is
completely broken when used on SLES 11 SP1, where the following error message occurs:
<div class="computeroutput">Unexpected error running operf: Permission denied
Please use the opcontrol command instead of operf.
A fix for this error is available upstream and will be available in 0.9.9. But the following
permanent restriction is in place when running on such older kernels:<br>
when running on such older kernels:<br>
<blockquote><em>When running <tt>operf</tt> as the root user using the syntax <tt>operf <command></tt>,
the profiling phase seems to succeed, but opreport shows no samples collected. The workaround is to use a non-root
user account for profiling a single application, and use the root user account only for <tt>--system-wide</tt> profiling.
<?php require("$top/end_page.php"); end_page("faq/"); ?>