[ oprofile-Bugs-663326 ] samples for modules in initrd have incorrect path

[SourceForge.net <noreply@so...>]

Bugs item #663326, was opened at 2003-01-06 20:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: William Cohen (wcohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: samples for modules in initrd have incorrect path

Initial Comment:
The method used to determine the path for modules
doesn't work correctly for modules that are loaded from
the initrd file at boot time.

I initially saw this problem on the Phoebe beta (hence
the .gz suffixes for the modules). The Phoebe beta uses
OProfile 0.4 with a a 2.4 kernel that has the Linux 2.5
interface backported to it.  I saw the following lines
of output from op_time:

137        0.1369 0.0000 /lib/ext3.o.gz
232        0.2318 0.0000 /lib/aic7xxx.o.gz
232        0.2318 0.0000 /lib/scsi_mod.o.gz
438        0.4375 0.0000 /lib/jbd.o.gz

The associated sample files in
/var/lib/oprofile/samples are:

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

The "/lib/" in the examples lines above should be 
"/lib/modules/2.4.20-2.2smp/..." This problem is caused
by the way that daemon_kernel.c extracts the path to
the module using /proc/ksyms. The modules loaded from
the initrd are not going to have the correct path in
/proc/ksyms. Looking at the code, it appears that this
problem still exists in the oprofile cvs head.

-Will

----------------------------------------------------------------------

>Comment By: John Levon (movement)
Date: 2003-01-07 04:32

Message:
Logged In: YES 
user_id=53034

Not a bug. We have no way of  getting the real path, the user
must specify where to find the module binaries :

       --path pathnamelist','separated, -p
pathnamelist','separated
              Specify  an  alternate  list  of pathname to
locate image
              file. This is usefull if your samples files
name does not
              match  the  image file name such as module
loaded at boot
              time through a ram disk

       --recursive-path path_list','separated, -P
path_list','separated
              Same as --path but retrieve recursively  the 
image  file
              name in the path list

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191

[ oprofile-Bugs-663326 ] samples for modules in initrd have incorrect path

[SourceForge.net <noreply@so...>]

Bugs item #663326, was opened at 2003-01-06 15:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: William Cohen (wcohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: samples for modules in initrd have incorrect path

Initial Comment:
The method used to determine the path for modules
doesn't work correctly for modules that are loaded from
the initrd file at boot time.

I initially saw this problem on the Phoebe beta (hence
the .gz suffixes for the modules). The Phoebe beta uses
OProfile 0.4 with a a 2.4 kernel that has the Linux 2.5
interface backported to it.  I saw the following lines
of output from op_time:

137        0.1369 0.0000 /lib/ext3.o.gz
232        0.2318 0.0000 /lib/aic7xxx.o.gz
232        0.2318 0.0000 /lib/scsi_mod.o.gz
438        0.4375 0.0000 /lib/jbd.o.gz

The associated sample files in
/var/lib/oprofile/samples are:

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

The "/lib/" in the examples lines above should be 
"/lib/modules/2.4.20-2.2smp/..." This problem is caused
by the way that daemon_kernel.c extracts the path to
the module using /proc/ksyms. The modules loaded from
the initrd are not going to have the correct path in
/proc/ksyms. Looking at the code, it appears that this
problem still exists in the oprofile cvs head.

-Will

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191

[ oprofile-Bugs-663326 ] samples for modules in initrd have incorrect path

[SourceForge.net <noreply@so...>]

Bugs item #663326, was opened at 2003-01-06 20:58
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: William Cohen (wcohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: samples for modules in initrd have incorrect path

Initial Comment:
The method used to determine the path for modules
doesn't work correctly for modules that are loaded from
the initrd file at boot time.

I initially saw this problem on the Phoebe beta (hence
the .gz suffixes for the modules). The Phoebe beta uses
OProfile 0.4 with a a 2.4 kernel that has the Linux 2.5
interface backported to it.  I saw the following lines
of output from op_time:

137        0.1369 0.0000 /lib/ext3.o.gz
232        0.2318 0.0000 /lib/aic7xxx.o.gz
232        0.2318 0.0000 /lib/scsi_mod.o.gz
438        0.4375 0.0000 /lib/jbd.o.gz

The associated sample files in
/var/lib/oprofile/samples are:

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

The "/lib/" in the examples lines above should be 
"/lib/modules/2.4.20-2.2smp/..." This problem is caused
by the way that daemon_kernel.c extracts the path to
the module using /proc/ksyms. The modules loaded from
the initrd are not going to have the correct path in
/proc/ksyms. Looking at the code, it appears that this
problem still exists in the oprofile cvs head.

-Will

----------------------------------------------------------------------

>Comment By: John Levon (movement)
Date: 2003-01-07 04:32

Message:
Logged In: YES 
user_id=53034

Not a bug. We have no way of  getting the real path, the user
must specify where to find the module binaries :

       --path pathnamelist','separated, -p
pathnamelist','separated
              Specify  an  alternate  list  of pathname to
locate image
              file. This is usefull if your samples files
name does not
              match  the  image file name such as module
loaded at boot
              time through a ram disk

       --recursive-path path_list','separated, -P
path_list','separated
              Same as --path but retrieve recursively  the 
image  file
              name in the path list

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=116191&aid=663326&group_id=16191