Bug 1452 - 32bit kernel generated oprofile data file can not be read by remote 64bit opreport
Summary: 32bit kernel generated oprofile data file can not be read by remote 64bit opr...
Status: RESOLVED OBSOLETE
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium normal
Target Milestone: 1.3
Assignee: Saul Wold
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2011-09-05 06:22 UTC by Lianhao Lu
Modified: 2012-08-28 05:54 UTC (History)
11 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lianhao Lu 2011-09-05 06:22:04 UTC
Branch: Poky/Master
Commit id: dfce2695b96ab587b8235cfab2859a874e9d2eef

When running oprofileUI on 64bit host machine to connect to 32bit target machine(qemux86, qemuarm, qemuppc), the data file generated by the yocto 3.0 kernel can not be read correctly by the host opreport(host oprofile is version 0.9.6). This would result the oprofileUI not working in this kin d of user case. 

The opreport command triggered by the oprofile-viewer reports the following errors:

opreport error: profile_t::samples_range(): start > end something wrong with kernel or module layout ?

Yocto 1.0 release with kernel 2.6.37 worked fine.
Comment 1 Lianhao Lu 2011-09-29 18:44:34 UTC
It seems by NOT "prelink" during do_rootfs time, the problem is gone.
Comment 2 Darren Hart 2011-12-20 09:26:58 UTC
Dexuan, could you verify this is still an issue in master. If so, could you accept the bug?
Comment 3 Dexuan Cui 2011-12-20 17:40:24 UTC
(In reply to comment #1)
> It seems by NOT "prelink" during do_rootfs time, the problem is gone.
Lianhao,
Could you please re-check if we still have the issue in recent poky master?
And, if we're sure this is a prelink issue, maybe we can ask Mark to have a look.  :-)

(In reply to comment #2)
> Dexuan, could you verify this is still an issue in master. If so, could you
> accept the bug?
Ok, we're re-checking it.
Comment 4 Lianhao Lu 2011-12-21 20:04:34 UTC
Branch: Poky/Master
Commit id:4648aadfe161d2e0ec51408f35fdf8996727bd22

The problem still exists in the latest poky/master.

This problem seems to me related to prelink. However. By not "prelink" during the do_rootfs time, the problem is gone. 

To reproduce this problem:
1. compile and install the oprofileUI on the host from git://git.yoctoproject.org/oprofileui.
2. launch the qemu, using image of core-image-sato-sdk(MACHINE=qemux86)
3. run oprofile-viewer on the host from the console, connect to the target in qemu, then click "start" and "stop". 

We'll see no chart got displayed in the oprofile-viewer, and an opreport error "profile_t::samples_range(): start > end something wrong with
kernel or module layout ?" displayed in the console.
Comment 5 Dexuan Cui 2011-12-25 22:35:12 UTC
(In reply to comment #4)
> Branch: Poky/Master
> Commit id:4648aadfe161d2e0ec51408f35fdf8996727bd22
> 
> The problem still exists in the latest poky/master.
Lianhao, thanks for the checking!
> 
> This problem seems to me related to prelink. However. By not "prelink" during
> the do_rootfs time, the problem is gone. 
Could Mark please have a look since this is prelink related? :-)

> 
> To reproduce this problem:
> 1. compile and install the oprofileUI on the host from
> git://git.yoctoproject.org/oprofileui.
> 2. launch the qemu, using image of core-image-sato-sdk(MACHINE=qemux86)
> 3. run oprofile-viewer on the host from the console, connect to the target in
> qemu, then click "start" and "stop". 
> 
> We'll see no chart got displayed in the oprofile-viewer, and an opreport error
> "profile_t::samples_range(): start > end something wrong with
> kernel or module layout ?" displayed in the console.
Comment 6 Saul Wold 2012-08-28 05:54:41 UTC
If oprofile-viewer is correctly installed on a system and the oparchconv is installed such that oprofile-viewer can find it, this seems to work correcly now.

I am going to close this as obsolete since it's an older bug that seems to work correctly now.  I confirmed this is with a prelinked image, if the problem reappears please reopen.