Several months ago oprofile just stopped working on my system. All I
have changed on the system was updating the kernel. This used to work
perfectly. I figured it was something I overlooked but recently I
double checked everything and I can't for the life of me figure out
what's wrong.
I am using the simple "profile" script that Andrew Morton posted several
months ago. But no matter what I do, all I get is:
opreport error: No sample file found: try running opcontrol --dump
or specify a session containing sample files
(Of course I have tried running opcontrol --dump, it has absolutely no
effect)
Examining the log files I see that it does not collect any samples.
root@mindpipe:~# cat /var/lib/oprofile/oprofiled.log
oprofiled started Thu Nov 3 16:32:05 2005
kernel pointer size: 4
Thu Nov 3 16:32:31 2005
Nr. sample dumps: 4
Nr. non-backtrace samples: 0
Nr. kernel samples: 0
Nr. lost samples (no kernel/user): 0
Nr. lost kernel samples: 0
Nr. incomplete code structs: 0
Nr. samples lost due to sample file open failure: 0
Nr. samples lost due to no permanent mapping: 0
Nr. event lost due to buffer overflow: 0
Nr. samples lost due to no mapping: 0
Nr. backtraces skipped due to no file mapping: 0
Nr. samples lost due to no mm: 0
Nr. samples lost cpu buffer overflow: 0
Nr. samples received: 0
Nr. backtrace aborted: 0
oprofiled stopped Thu Nov 3 16:32:31 2005
Is there something in the -rt tree that's known to break oprofile? Or
did the userspace interface change in an incompatible way?
Lee
On Thu, 2005-11-03 at 16:39 -0500, Lee Revell wrote:
> I am using the simple "profile" script that Andrew Morton posted several
> months ago. But no matter what I do, all I get is:
>
> opreport error: No sample file found: try running opcontrol --dump
> or specify a session containing sample files
>
> (Of course I have tried running opcontrol --dump, it has absolutely no
> effect)
>
> Examining the log files I see that it does not collect any samples.
I just tested this with oprofile both built into the kernel and as a
module, and with oprofile userspace tools 0.9.1 and from CVS. No
change. I have verified that /dev/oprofile is mounted. It looks like
the profiler never sees any samples.
rlrevell@mindpipe:~$ cat /dev/oprofile/stats/cpu0/sample_received
0
Could one of the ktimers changes have broken the timer interrupt based
profiling?
Lee
On Thu, 2005-11-03 at 18:22 -0500, Lee Revell wrote:
> I just tested this with oprofile both built into the kernel and as a
> module, and with oprofile userspace tools 0.9.1 and from CVS. No
> change. I have verified that /dev/oprofile is mounted. It looks like
> the profiler never sees any samples.
>
> rlrevell@mindpipe:~$ cat /dev/oprofile/stats/cpu0/sample_received
> 0
>
> Could one of the ktimers changes have broken the timer interrupt based
> profiling?
I have verified that oprofile does work with 2.6.14. So the breakage is
unique to the -rt kernel.
Lee
(replying to a very old thread)
On Sun, 2005-11-06 at 13:45 -0500, Lee Revell wrote:
> On Thu, 2005-11-03 at 18:22 -0500, Lee Revell wrote:
> > I just tested this with oprofile both built into the kernel and as a
> > module, and with oprofile userspace tools 0.9.1 and from CVS. No
> > change. I have verified that /dev/oprofile is mounted. It looks like
> > the profiler never sees any samples.
> >
> > rlrevell@mindpipe:~$ cat /dev/oprofile/stats/cpu0/sample_received
> > 0
> >
> > Could one of the ktimers changes have broken the timer interrupt based
> > profiling?
>
> I have verified that oprofile does work with 2.6.14. So the breakage is
> unique to the -rt kernel.
Ingo,
oprofile still does not work with the -rt kernel (verified with
2.6.16-rt20).
Can anyone else reproduce this?
Lee