oprofile failure on panda (omap4)

Avik, I know you've tested oprofile for natty and confirmed that it's working; can you have a look at this bug?

I could not reproduce this bug on the Beagle Board running Linaro. Although I could not test the same on Panda Board so far due to other issues in booting Linaro on Panda Board.

Tobin, can you try reproducing this issue with our latest image available? Thanks in advance.

Ok, I have tried this following the above steps on the 20110216/natty-preinstalled-netbook-armel images for omap (beaglexm) and omap4 (panda) with the latest updates. On the beaglexm it produces a report, however on the panda it does not.
The panda image currently uses 2.6.35-1101-omap4 kernel.

Other experiments I tried:
panda with nosmp kernel parameter (disables 2nd cpu): same results
panda with 2.6.38-1202 from kernel-team ppa: same results

The expected results look something like this (see http://paste.ubuntu.com/570812/ for the complete output from beagle XM):
CPU: ARM Cortex-A8, speed 0 MHz (estimated)
Counted CPU_CYCLES events (Number of CPU cycles) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CYCLES:100000|
  samples| %|
------------------
   193159 70.4929 no-vmlinux
    22737 8.2978 libxapian.so.22.2.0
    20779 7.5832 libc-2.13.so
.
.
.

What panda produces is only this:
error: no sample files found: profile specification too strict ?

I am currently waiting on the 2.6.38-1204 kernel to finish building and will test it, but my expectations are low.

Also retested on panda running Maverick, and passed there. This is a regression on natty for panda only.

> The panda image currently uses 2.6.35-1101-omap4 kernel.

Seems to work fine with the Linaro 2.6.37 kernel, so looks like a bug in the panda BSP kernel. Reassigning.

Changing back to oprofile as this test works correctly when running the current natty kernel for panda on a maverick image.

I could reproduce the bug on panda running Linaro natty with 2.6.37 kernel. It seems the profile data are not getting written to $SESSION_DIR/samples directory.

This appears in dmesg which points to a kernel issue.

hw perfevents: unable to reserve pmu

This discussion seems to imply CONFIG_PM related code not being active in the kernel they test with, may be related to what we need to do in natty.
http://groups.google.com/group/pandaboard/browse_thread/thread/74abf5dafa2fd6e2/fc22588f7cceadd7

It seems that the patch in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html is going to fix the issue by enabling pmu events for omap4, which are routed from CTI. The patch attached is a version of the above with removal of some CTI register reads that cause hang in the initial phase of booting. The patch has been verified on Panda board and the profile data could be generated that are shown by opreport. Although, there is a lockdep warning "possible circular locking dependency detected" when "opcontrol --start" is called for the first time.

Since this is a kernel bug, the fix will need to be applied separately to each of the kernel trees for omap4. I'm told that this has been staged for inclusion in linux-linaro-omap already.

Hi Avik Sil,

I have tried the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html
plus the patch in http://marc.info/?t=130568614100001&r=1&w=2.

On natty over my A1 pandaboard, perf can work well, seems no need to remove some read operations in
cti.h.

thanks,
Ming Lei

the history of oprofile/arm in Ubuntu is a bit weird:

in Precise it was removed since it was unmantained (https://launchpad.net/ubuntu/precise/+source/oprofile/0.9.6-1.3ubuntu1)

in Quantal it was reintroduced but there's no armhf version of the package (only i386/amd64 and armel - https://launchpad.net/ubuntu/+source/oprofile/0.9.8-0ubuntu1)

and Oneiric is pretty much unused as far as arm is concerned

I'm marking this as Won't fix, and I'll follow with a patch to make oprofile compiles on armhf: from there on people can reopen bugs for oprofile on arm

Migrated to bugzilla: https://bugs.linaro.org/show_bug.cgi?id=559