Bug 81024

Summary:	oprofile incorrect sample filenames
Product:	[Retired] Red Hat Linux	Reporter:	William Cohen <wcohen>
Component:	oprofile	Assignee:	William Cohen <wcohen>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	0.5.4-22	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-08-27 17:18:53 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.