headers
John Lumby | 3 Aug 2004 00:02
Picon
Favicon

oprofile 0.8 on linux kernel 2.6.7

I last used profile on 2.65.0, and in that kernel there were the two .config 
optinos for PROFILing.    In 2.6.7 those options aren't there, so I assumed 
oprofiling support is built in automatically.  However after building the 
kernel and oprofile,  when I try
opcontrol --vmlinux=/boot/vmlinux-`uname -r`
          it reports
FATAL: Module oprofile not found.
FATAL: Module oprofile not found.
Kernel doesn't support oprofile

From looking in the script it seems it is still expecting a module but the 
make did not build one.    Also I tried
mount -t oprofilefs nodev /dev/oprofile
   which replied
mount: fs type oprofilefs not supported by kernel

I see other postings referring to running on 2.6.7 so I must have done 
something stupid, but what?

John

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology 

http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alex Tsariounov | 3 Aug 2004 00:52
Picon

Re: oprofile 0.8 on linux kernel 2.6.7

On Mon, Aug 02, 2004 at 06:02:25PM -0400, John Lumby wrote:
> I last used profile on 2.65.0, and in that kernel there were the two 
> .config optinos for PROFILing.    In 2.6.7 those options aren't there, so I 
> assumed oprofiling support is built in automatically.  However after 

It's not and the options are still there.  If you do menuconfig:

main menu->Profiling support->Profiling support->Oprofile system profiling

Alex

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Permalink | Reply | 0 comments |
headers
John Lumby | 3 Aug 2004 05:13
Picon
Favicon

Re: oprofile 0.8 on linux kernel 2.6.7

Ah - thanks - I discovered that the PROFILing options are conditioned on 
selecting the EXPERIMENTAL option which I had unset.     Should be fine now. 
   Also, of course, in my earlier post, "2.65.0" should have read 2.6.0"

Thanks    John
----Original Message Follows----
From: alext <at> fc.hp.com (Alex Tsariounov)
To: John Lumby <johnlumby <at> hotmail.com>
CC: oprofile-list <at> lists.sourceforge.net
Subject: Re: oprofile 0.8 on linux kernel 2.6.7
Date: Mon, 2 Aug 2004 16:52:56 -0600

On Mon, Aug 02, 2004 at 06:02:25PM -0400, John Lumby wrote:
 > I last used profile on 2.65.0, and in that kernel there were the two
 > .config optinos for PROFILing.    In 2.6.7 those options aren't there, so 
I
 > assumed oprofiling support is built in automatically.  However after

It's not and the options are still there.  If you do menuconfig:

main menu->Profiling support->Profiling support->Oprofile system profiling

Alex

_________________________________________________________________
Scan and help eliminate destructive viruses from your inbound and outbound 
e-mail and attachments.

http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luca Rossato | 3 Aug 2004 16:42
Picon
Favicon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

Hello Zwane and everybody.
Sorry for the delay in answering, I was on a short vacation. The backport
went well and everything seems to be working fine now!
I have to say that it took me a lot longer than a day or two, but that's
mostly because I had neither any previous knowledge of oprofile's inner
workings, nor any experience with Linux kernel programming (I am mostly a
Windows developer).
Trying to reuse Red Hat's backport was much more trouble than it was worth,
for several reasons:
a) as I said in a previous post, the kernel I was working on was very
different from the one used by Red Hat, despite having the same version
number, because of the tons of patches that had been applied to both;
b) Red Hat's backporting effort revolved mainly around the x86 architecture,
and of course had no support for ARM or XScale;
c) most important, Red Hat's backport had been done on oprofile-0.5.4,
whereas the code for ARM support in oprofile was written for version 0.8. I
discovered the hard way (with a lot of debugging and trudging through the
source files) that the data format used in the event buffers underwent a few
small changes between the two versions, and those changes were enough to
always crash the daemon during the dump. There is no comment on the changes
in the docs, and even on this list it was mentioned that the only thing I
needed to do in order to move from 0.5.4 to 0.8 was implement
/dev/oprofile/pointer_size in the kernel.
To complicate matters further, about in the middle of the process we
switched the kernel version used on the development board from KELP to
MontaVista.

Anyway, all's well that ends well, and I'm most grateful to everybody that
answered and in general to everybody that worked on oprofile's development.
I would like to add my contribute with a small patch (please find it
(Continue reading)

Permalink | Reply | 7 comments |
headers
Zwane Mwaikambo | 3 Aug 2004 18:28
Picon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

Hi Luca,

On Tue, 3 Aug 2004, Luca Rossato wrote:

> Anyway, all's well that ends well, and I'm most grateful to everybody that
> answered and in general to everybody that worked on oprofile's development.
> I would like to add my contribute with a small patch (please find it
> attached) that fixes a bug I have found with the PMU programming on the
> Intel PXA27x. In short, the code that reads and writes the pmnc on the
> XScale 2 architecture uses the wrong masks for write-as-0 and
> read-unpredictable bits; this makes the clock cycle counter behave
> erratically, because the 64x clock prescaler gets activated randomly.
> The patch works fine on the PXA27x, which AFAIK is the only processor that
> uses the XScale 2 microarchitecture.

Thanks for working on that, actually the IOP331 i developed the code on is
an XScale 2. As for the patch, there is one i'm curious about;

 <at>  <at>  -139,8 +144,11  <at>  <at> 

        if (pmu->id == PMU_XSC1)
                __asm__ __volatile__ ("mrc p14, 0, %0, c0, c0, 0" : "=r" (val));
-       else
+       else {
                __asm__ __volatile__ ("mrc p14, 0, %0, c0, c1, 0" : "=r" (val));
+               /* bits 1-2 and 4-23 are read-unpredictable */
+               val &= 0xff000009;
+       }

        return val;
(Continue reading)

Permalink | Reply | 6 comments |
headers
Luca Rossato | 3 Aug 2004 19:55
Picon
Favicon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

> For the read case i don't think we have to care since we take care of this
> when writing back to the PMNC.

Actually the read operation was part of the problem. For instance, near the
end of function xscale_pmu_interrupt, we have:

    pmnc = read_pmnc() | PMU_ENABLE;
    write_pmnc(pmnc);

The PMNC is read and then written back immediately, apparently only changing
bit 0 (Enable). However, at least on the PXA27x, a.k.a. Bulverde (I don't
have the docs for the IOP331), bits 1 and 2 are read-unpredictable, so if we
don't mask them out in read_pmnc, they get assigned a random value in the
pmnc variable. When the variable contents are written back to the hardware
register with write_pmnc, if bit 2 was read as a "1" we have a Clock Counter
Reset, and even worse, if bit 1 happened to be read as a "1" we have a
Performance Counter Reset (all performance counters get reset to 0x0)!

So, I believe that it's necessary to force all read-unpredictable bits to 0
between read and write operations (especially bits 1-2 which are
"dangerous"). Whether to do it in read_pmnc or afterwards in write_pmnc,
it's a matter of choice.

Luca

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
(Continue reading)

Permalink | Reply | 5 comments |
headers
Zwane Mwaikambo | 4 Aug 2004 05:25
Picon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

On Tue, 3 Aug 2004, Luca Rossato wrote:

> The PMNC is read and then written back immediately, apparently only changing
> bit 0 (Enable). However, at least on the PXA27x, a.k.a. Bulverde (I don't
> have the docs for the IOP331), bits 1 and 2 are read-unpredictable, so if we
> don't mask them out in read_pmnc, they get assigned a random value in the
> pmnc variable. When the variable contents are written back to the hardware
> register with write_pmnc, if bit 2 was read as a "1" we have a Clock Counter
> Reset, and even worse, if bit 1 happened to be read as a "1" we have a
> Performance Counter Reset (all performance counters get reset to 0x0)!
>
> So, I believe that it's necessary to force all read-unpredictable bits to 0
> between read and write operations (especially bits 1-2 which are
> "dangerous"). Whether to do it in read_pmnc or afterwards in write_pmnc,
> it's a matter of choice.

That's the point, the original code (as does yours) did the mask on
writeback, most of the readers don't care. Do you observe breakage if it's
only done on writeback?

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Permalink | Reply | 4 comments |
headers
Luca Rossato | 4 Aug 2004 10:10
Picon
Favicon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

> That's the point, the original code (as does yours) did the mask on
> writeback, most of the readers don't care. Do you observe breakage if it's
> only done on writeback?

But in the original code the write mask is

 val &= 0xffff77f;

and that leaves bit 1 and 2 unchanged. So if they happen to be read as 1s,
they get written back as 1s and reset the counters...

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Permalink | Reply | 3 comments |
headers
Zwane Mwaikambo | 5 Aug 2004 22:04
Picon

Re: Backporting oprofile to 2.4 kernels (XScale arch)

On Wed, 4 Aug 2004, Luca Rossato wrote:

> > That's the point, the original code (as does yours) did the mask on
> > writeback, most of the readers don't care. Do you observe breakage if it's
> > only done on writeback?
>
> But in the original code the write mask is
>
>  val &= 0xffff77f;
>
> and that leaves bit 1 and 2 unchanged. So if they happen to be read as 1s,
> they get written back as 1s and reset the counters...

Ah yes, it breaks XScale2 gotcha.

-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
Permalink | Reply | 2 comments |
headers
Matt Rice | 7 Aug 2004 06:16
Picon
Favicon

line number info with objective-c mangled symbols

around libutil++/op_bfd.cpp:577 in op_bfd::get_linenr

if (ret && functionname && sym.name !=
string(functionname) {
 <snip>
  if (sym.name().find(functionname) == string::npos)
    ret = false;
}

in objective-c sym.name is the mangled symbol name,
and functionname is the demangled function name, but
the functionname is not a substring of sym.name so
op_bfd::get_linenr returns false.

here's an example
sym.name:
_i_GSUnicodeString__rangeOfCharacterSetFromSet_options_range

functionname:
-[GSUnicodeString
rangeOfCharacterFromSet:options:range:]

other than that it works great.
matt

		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
(Continue reading)

Permalink | Reply | 0 comments |

Gmane