Menu
▾
▴
Re: opreport -l produces segfault with oprofile-0.9.7 + stack trace is attached
|
From: Maynard J. <may...@us...> - 2012-12-05 18:33:32
|
On 12/05/2012 10:31 AM, Koteswararao Nelakurthi wrote: > Dear Maynard Johnson, > > Thanks for your information. > I will test opreport withlatest oprofile-0.9.8 and update you soon. > Mean while please find the stacktrace for opreport segfault that i forgot That's an strace, which doesn't really help. You need to run opreport under gdb and then do a 'backtrace' gdb command when it hits the seg fault. -Maynard > to attach with previous mail. > > Thanks > koteswararao. > > On Wed, Dec 5, 2012 at 8:35 PM, Maynard Johnson <may...@us... <mailto:may...@us...>> wrote: > > On 12/05/2012 01:30 AM, Koteswararao Nelakurthi wrote: > > Dear Developers, > > > > I have gone through one of sourceforge.net <http://sourceforge.net> <http://sourceforge.net> mailing list and observed this segfault issue during execution of 'opreport -l' command. > > > > http://sourceforge.net/tracker/?func=detail&aid=2798666&group_id=16191&atid=116191 <http://sourceforge.net/tracker/?func=detail&aid=2798666&group_id=16191&atid=116191> <http://sourceforge.net/tracker/?func=detail&aid=2798666&group_id=16191&atid=116191 <http://sourceforge.net/tracker/?func=detail&aid=2798666&group_id=16191&atid=116191>> > > > > But no solution is reached in above link > > Hello. In fact, the bug report you referenced above *was* solved by building oprofile with an appropriate binutils package. We don't know if you're experiencing the same problem as the submitter of that bug since you didn't provide a backtrace of your seg fault. We've had no valid reports of seg faults in opreport for oprofile 0.9.7. Nevertheless, I suggest you update oprofile to 0.9.8, and then, if you still get the seg fault, please post a new message thread (instead of reusing your original "OProfile startup issue for ARMv7 + CortexA9 based board" message) with a full backtrace of the seg fault (i.e., run opreport under gdb). > > Thanks. > > -Maynard > > > > > Regards > > koteswararao. > > > > On Wed, Dec 5, 2012 at 10:54 AM, Koteswararao Nelakurthi <kne...@mv... <mailto:kne...@mv...> <mailto:kne...@mv... <mailto:kne...@mv...>>> wrote: > > > > Dear Developers, > > > > I am able to resolve above issue. > > Now i am able to profile the kernel image etc. > > But i observed below issue during analyzing profile results. > > {{{ > > > > root@xilinx-zynq-le:~# opcontrol --start --vmlinux=/boot/vmlinux > > Using default event: CPU_CYCLES:100000:0:1:1 > > Using 2.6+ OProfile kernel interface. > > Reading module info. > > Using log file /var/lib/oprofile/samples/oprofiled.log > > Daemon started. > > Profiler running. > > > > root@xilinx-zynq-le:~# opcontrol --dump > > > > root@xilinx-zynq-le:~# opreport > > CPU: ARM Cortex-A9, speed 1999 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| %| > > ------------------ > > 15 65.2174 vmlinux > > 4 17.3913 ld-2.11.1.so <http://ld-2.11.1.so> <http://ld-2.11.1.so> > > 2 8.6957 libc-2.11.1.so <http://libc-2.11.1.so> <http://libc-2.11.1.so> > > 1 4.3478 busybox > > 1 4.3478 libgcc_s.so.1 > > root@xilinx-zynq-le:~# > > }}} > > > > {{{ > > root@xilinx-zynq-le:~# opreport -l > > CPU: ARM Cortex-A9, speed 1999 MHz (estimated) > > Counted CPU_CYCLES events (Number of CPU cycles) with a unit mask of 0x00 (No > > unit mask) count 100000 > > Segmentation fault > > root@xilinx-zynq-le:~ > > > > > > }}} > > > > {{{ > > root@xilinx-zynq-le:~# opreport -l > > CPU: ARM Cortex-A9, speed 1999 MHz (estimated) > > Counted CPU_CYCLES events (Number of CPU cycles) with a unit mask of 0x00 (No > > unit mask) count 100000 > > Segmentation fault > > root@xilinx-zynq-le:~ > > > > }}} > > > > Any input regarding the segfault issue during the execution of opreport -l command? > > > > Thanks > > koteswararao. > > > > > > On Tue, Dec 4, 2012 at 10:37 PM, Will Deacon <wil...@ar... <mailto:wil...@ar...> <mailto:wil...@ar... <mailto:wil...@ar...>>> wrote: > > > > Hi guys, > > > > On Tue, Dec 04, 2012 at 04:35:17PM +0000, Maynard Johnson wrote: > > > *Will*, can you provide any insight here? > > > > Well, to be honest, I'm not entirely following what's going on: > > > > > > int armv7_setup_pmnc(void) > > > > { > > > > unsigned int cnt; > > > > > > > > if (armv7_pmnc_read() & PMNC_E) { <--- failure condition > > > > [...] > > > > > > I tried to read armv7_pmnc_read() value while starting profiling and it's is > > > > shown as 0x41093009 as given below. > > > > [...] > > > > > > I cross checked xilinx TRM for PMNC (performance monitor control Register) > > > > reset value and it is specified as 0x41093000. Since PMCR value is invalid in > > > > our case hence the error message specified above is observed. > > > > This basically means that the PMU is being enabled by something else. > > Depending on whether you've got something hacked into your kernel, it could > > be that, otherwise it could be a hangover from some software that ran > > before. > > > > However, since armv7_setup_pmnc doesn't even exist in my kernel, I'm kind of > > stuck with what to suggest. Can you try with mainline please? > > > > Will > > > > > > > > |