Bug 81024 - oprofile incorrect sample filenames
Summary: oprofile incorrect sample filenames
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: oprofile
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: William Cohen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-01-03 16:04 UTC by William Cohen
Modified: 2007-04-18 16:49 UTC (History)
0 users

Fixed In Version: 0.5.4-22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-08-27 17:18:53 UTC
Embargoed:


Attachments (Terms of Use)

Description William Cohen 2003-01-03 16:04:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Some of the sample file names being used by oprofile to store files in
/var/lib/oprofile/samples are incorrect.

Using the 2.4.20-2.2smp kernel and oprofile-0.4-16 on a P4 machine.

For example after running oprofile for a while measuring GLOBAL_POWER_EVENTS and
the examining the data with op_time find that some of the modules do not have
the correct path listed in op_time

5015       0.2122 0.0000 /lib/scsi_mod.o.gz
5654       0.2392 0.0000 /lib/aic7xxx.o.gz
8770       0.3711 0.0000 /lib/ext3.o.gz
14901      0.6305 0.0000 /lib/jbd.o.gz

Looking in /var/lib/oprofile/sample the corresponding files are

}lib}scsi_mod.o.gz#0
}lib}aic7xxx.o.gz#0
}lib}ext3.o.gz#0
}lib}jbd.o.gz#0

These should be

/lib/modules/2.4.20-2.2smp/...


Version-Release number of selected component (if applicable):


How reproducible:
Didn't try

Steps to Reproduce:
  

Actual Results:  No every file in /var/lib/oprofile/samples maps back to a file
on the machine.

Expected Results:  Expect that each file in /var/lib/oprofile/samples maps back
to a file on the machine.

Additional info:

Comment 1 William Cohen 2003-01-03 20:17:50 UTC
oprofile gets the path for the module from /proc/ksyms. It appears that the
/proc/ksyms has incorrect information for some of the modules.

dfd20000 __insmod_ext3_O/lib/ext3.o.gz_M3E035AEB_V132116        [ext3]
dfd50000 __insmod_jbd_O/lib/jbd.o.gz_M3E035AEB_V132116  [jbd]
dfd80000 __insmod_aic7xxx_O/lib/aic7xxx.o.gz_M3E035AE5_V132116  [aic7xxx]
dfdf0000 __insmod_sd_mod_O/lib/sd_mod.o.gz_M3E035AE4_V132116    [sd_mod]
c2200000 __insmod_scsi_mod_O/lib/scsi_mod.o.gz_M3E035AE4_V132116        [scsi_mod]

Comment 2 William Cohen 2003-01-03 20:39:23 UTC
The problem is due to the way that oprofiled obtains the path for a module.
oprofiled extracts the information from /proc/ksyms. Unfortunately, modules in
the initrd are have different path. Thus, modules loaded from the initrd do not
have an appropriate path in the /proc/ksyms.

Comment 3 Bill Nottingham 2003-01-06 21:25:54 UTC
oprofile could do a filetree walk under /lib/modules/`uname -r`/ to find the
correct path. (Just an idea.)

Comment 4 William Cohen 2004-08-27 17:18:53 UTC
For RHEL3 oprofile (oprofile-0.5.4-22)
opd_kernel.c:opd_reread_module_info() obtains the information from
/proc/ksyms for example and entry from /proc/ksyms:

e0db6000
__insmod_cast6_O/lib/modules/2.4.21-20.ELsmp/kernel/crypto/cast6.o_M412


Note that oprofile-0.8 has completely different logic for handling the
modules and that won't give the complet path to modules.


Note You need to log in before you can comment on or make changes to this bug.