Discussion:
Regarding vmlinux file for opcontrol --init
(too old to reply)
dhara buch
2017-02-27 16:33:37 UTC
Permalink
Raw Message
Hello,

I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile
with'
opcontrol --init command, which requires uncompressed vmlinux file with
--vmlinux option.

I have tried to uncompress the present vmlinuz with extract-vmlinux script.
The file gts uncompressed,but when I init opcontrol with this uncompressed
file, my CPU type gets wrongly identified. Hence, although the hardware
events are supported by the processor, 'timer' mode gets set and event
monitoring doesn't become possible.

I would be thankful if anybody can guide me to solve this problem.

Dhara Buch
Michael Petlan
2017-02-27 16:54:28 UTC
Permalink
Raw Message
Post by dhara buch
Hello,
Hi Dhara,
Post by dhara buch
I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol with this uncompressed file, my CPU type gets wrongly
identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring doesn't become possible.
You can test the CPU identification by running `ophelp -r` which should
print what OProfile thinks your CPU is, such as:

$ ophelp -r
Intel Skylake microarchitecture

What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
the newer processors. Consider using the latest OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
well.

Regards,
Michael
Post by dhara buch
I would be thankful if anybody can guide me to solve this problem.
Dhara Buch
Michael Petlan
2017-02-27 18:30:15 UTC
Permalink
Raw Message
Post by dhara buch
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
goes also to oprofile-***@lists.sourceforge.net --> others
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
I am using i7 core processor. When I executed ophelp -r, the displayed CPU type was  'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
The important fields are cpu model and cpu family:

Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Post by dhara buch
Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am also not much clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.

Regarding to vmlinux:

You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.

Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.

However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.

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

Some deeper explanation:

There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".

--

1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.

The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).

The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.

Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".

The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.

--

2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.

Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.

If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.

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

So, I recommend to update to the latest OProfile and try out the
operf mode:

1) `ophelp -r` should still test the CPU identification

I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.

2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).

3) `ophelp | less` will print all the HW events available to you

4) Basic profiling:

operf ls
opreport

5) or let's profile systemwide and with kernel:

operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport

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

Hope it helps.
Michael
Post by dhara buch
Dhara Buch
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol with this uncompressed file, my CPU
type gets wrongly
identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring doesn't become possible.
You can test the CPU identification by running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
the newer processors. Consider using the latest OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can guide me to solve this problem.
Dhara Buch
dhara buch
2017-02-28 07:10:34 UTC
Permalink
Raw Message
---------- Forwarded message ----------
From: Michael Petlan <***@redhat.com>
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Post by dhara buch
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
goes also to oprofile-***@lists.sourceforge.net --> others
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
I am using i7 core processor. When I executed ophelp -r, the displayed CPU
type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
The important fields are cpu model and cpu family:

Vendor ID: GenuineIntel
CPU family: 6
Model: 78

Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of
Post by dhara buch
vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am also not much clear about
the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.

Regarding to vmlinux:

You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.

Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.

However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.

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

Some deeper explanation:

There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".

--

1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.

The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).

The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.

Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".

The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.

--

2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.

Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.

If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.

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

So, I recommend to update to the latest OProfile and try out the
operf mode:

1) `ophelp -r` should still test the CPU identification

I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.

2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).

3) `ophelp | less` will print all the HW events available to you

4) Basic profiling:

operf ls
opreport

5) or let's profile systemwide and with kernel:

operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport

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

Hope it helps.
Michael
Post by dhara buch
Dhara Buch
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which requires uncompressed vmlinux
file with --vmlinux option.
I have tried to uncompress the present vmlinuz with
extract-vmlinux script. The file gts uncompressed,but when I init opcontrol
with this uncompressed file, my CPU
type gets wrongly
identified. Hence, although the hardware events are supported
by the processor, 'timer' mode gets set and event monitoring doesn't become
possible.
You can test the CPU identification by running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
the newer processors. Consider using the latest OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can guide me to solve this problem.
Dhara Buch
dhara buch
2017-02-28 07:33:34 UTC
Permalink
Raw Message
I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me
output as 'Intel Broadwell Microarchitecture as output'.

Then I executed operf command without any option, but it gave me an error
as follows:
ou
Your kernel's performance event subsystem does not support your processor
type.

What is the solution?

Thank y
Post by dhara buch
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Post by dhara buch
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
Post by dhara buch
I am using i7 core processor. When I executed ophelp -r, the displayed
CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of
Post by dhara buch
vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am also not much clear about
the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Post by dhara buch
Dhara Buch
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which requires uncompressed vmlinux
file with --vmlinux option.
I have tried to uncompress the present vmlinuz with
extract-vmlinux script. The file gts uncompressed,but when I init opcontrol
with this uncompressed file, my CPU
type gets wrongly
identified. Hence, although the hardware events are supported
by the processor, 'timer' mode gets set and event monitoring doesn't become
possible.
You can test the CPU identification by running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
the newer processors. Consider using the latest OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can guide me to solve this problem.
Dhara Buch
Michael Petlan
2017-02-28 12:50:57 UTC
Permalink
Raw Message
I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
 
ou
Your kernel's performance event subsystem does not support your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.

Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.

You can verify that PMU is working by:

$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event counts (actual) for /usr/bin/ls:
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00

or using perf (linux-tools package), by

$ perf stat -e cycles ls
Performance counter stats for 'ls':
3,737,940 cycles
0.013856521 seconds time elapsed

I think this should work without any necessary patches if
you enable PMU for the guest.

Cheers,
Michael
What is the solution?
Thank y
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
I am using i7 core processor. When I executed ophelp -r, the displayed CPU type was  'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 78
Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am also not much clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
            Hello,
      Hi Dhara,
            I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
            opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option.
            I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol with this uncompressed
file, my CPU
            type gets wrongly
            identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring doesn't become possible.
      You can test the CPU identification by running `ophelp -r` which should
      $ ophelp -r
      Intel Skylake microarchitecture
      What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
      the newer processors. Consider using the latest OProfile 1.1. It might not
      fit you if you need the legacy opcontrol-based profiling mode (which was
      removed from 1.0 and above), but since you probably want to use the CPU
      hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
      well.
      Regards,
      Michael
            I would be thankful if anybody can guide me to solve this problem.
            Dhara Buch
dhara buch
2017-03-02 14:43:28 UTC
Permalink
Raw Message
Hi,

I checked the status of PMU. Referring to log, I found a note as :



*Performance Events: unsupported p6 CPU model he 61 no PMU driver, software
events only.*
61 is my CPU model No.

As per my study, if I am not wrong this is given by linux, not Xen . Due to
this probably PMU is not getting enabled.

Can you help me out in solving this?

Thanks
Post by Michael Petlan
Post by dhara buch
I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me
output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
Post by dhara buch
ou
Your kernel's performance event subsystem does not support your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
3,737,940 cycles
0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
Post by dhara buch
What is the solution?
Thank y
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
I am using i7 core processor. When I executed ophelp -r, the
displayed CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol --vmlinux=(uncompressed
form of vmlinuz) command, the CPU type gets changed to 'CPU with timer
Interrupt'.
The problem would be in uncompressed file? I am also not much
clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on Ubuntu 15.10.
I try to init oprofile with'
opcontrol --init command, which requires
uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the present vmlinuz
with extract-vmlinux script. The file gts uncompressed,but when I init
opcontrol with this uncompressed
file, my CPU
type gets wrongly
identified. Hence, although the hardware events
are supported by the processor, 'timer' mode gets set and event monitoring
doesn't become possible.
You can test the CPU identification by running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is pretty old, it
might not support
the newer processors. Consider using the latest
OProfile 1.1. It might not
fit you if you need the legacy opcontrol-based
profiling mode (which was
removed from 1.0 and above), but since you probably want to use the CPU
hardware events, I guess, operf-mode (and oprofile-1.1)
should serve you
well.
Regards,
Michael
I would be thankful if anybody can guide me to
solve this problem.
Dhara Buch
Michael Petlan
2017-03-02 16:49:38 UTC
Permalink
Raw Message
Hi,

Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
want to check whether your kernel has this patch:

commit 91f1b70582c62576f429cf78d53751c66677553d
Author: Andi Kleen <***@linux.intel.com>
Date: Tue Feb 17 18:18:05 2015 -0800

perf/x86/intel: Add Broadwell core support

That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).

You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.

The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.

You might try to update to some newer kernel to solve it.

It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.

Michael


[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux, not Xen . Due to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
 
ou
Your kernel's performance event subsystem does not support your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
        Event                   Count                    % time counted
        cpu_clk_unhalted        3,982,864                100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
         3,737,940      cycles
       0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
What is the solution?
Thank y
      ---------- Forwarded message ----------
      Date: Tue, Feb 28, 2017 at 12:00 AM
      Subject: Re: Regarding vmlinux file for opcontrol --init
            Hello,
            Thanks a lot for the prompt reply.
      Hi, you're welcome. Please do Reply-To-All to make sure it all
      might appreciate the list history for solving similar problems
      in future.
            I am using i7 core processor. When I executed ophelp -r, the displayed CPU type was  'Intel Architectural Perfmon'.
      The "Core i7" is too generic nomenclature. Could you please send
      the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
      Vendor ID:             GenuineIntel
      CPU family:            6
      Model:                 78
            Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed to 'CPU with timer Interrupt'.
            The problem would be in uncompressed file? I am also not much clear about the proper way to get vmlinux from vmlinuz file.
      I think you decompressed the file correctly. However, this does
      not affect the CPU identification/understanding.
      You can even skip vmlinux by using "--no-vmlinux" switch with
      opcontrol. That will mark all the samples captured in kernel as
      "no-vmlinux" and no vmlinux file is needed. However, this is no
      good if you want to profile kernelspace.
      Your problem is that your CPU is not identified by OProfile.
      If you send me the `lscpu` output or the /proc/cpuinfo file
      contents, I might figure out why.
      However, it is very probable, that your CPU is supported by the
      latest OProfile 1.1 and I encourage you to try that one instead.
      ------------
      There are two modes oprofile knows, let's call them "opcontrol-mode"
      and "operf-mode".
      --
      1) "opcontrol-mode" is obsolete and consists of a kernel module,
      a profiling daemon and a controller (opcontrol). By this controller,
      you signal the profiling daemon to start/stop/reset profiling, etc.
      The event sources can be either HW events or TIMER interrupt. The
      TIMER interrupt is a fallback used by the daemon when HW events are
      not detected. They are not detected when the CPU is unknown or not
      supported. It might be also totally different architecture which
      does not support any HW events, or, the HW events might be disabled
      (e.g. you are running a virtual machine and the hypervisor does not
      support/enable that for its guests).
      The "TIMER interrupts" is a software-emulated event that is used
      when the HW events are simply not available.
      Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
      mode". So using "TIMER interrupts" might be a reason why a user might
      want to stick with this legacy "opcontrol-mode".
      The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
      the latest OProfile that supports it.
      --
      2) "operf-mode" is far better replacement for the previous mode. It
      does not need any daemon and kernel module, the usage is much more
      simple and it has lots of other advantages.
      Basically, the only disadvantage is that it does NOT support the
      TIMER interrupts fallback. Thus, when the HW events are not enabled/
      detected/usable/supported/etc, you cannot fallback to the TIMER mode.
      If you do not want to use the TIMER mode, there is basically no
      reason for not using "operf-mode" instead, thus there is nothing to
      be lost by updating to oprofile-1.1.
      --------------------
      So, I recommend to update to the latest OProfile and try out the
      1) `ophelp -r` should still test the CPU identification
      I believe, your CPU will be supported after updating, but I cannot
      be sure without knowing the model/family numbers.
      2) `ocount ls` should report some numbers (this tests whether the
      HW events can be used).
      3) `ophelp | less` will print all the HW events available to you
      operf ls
      opreport
      operf -s --vmlinux /your/path/to/vmlinux
      # wait here for a while
      ^C
      opreport
      ------------------------
      Hope it helps.
      Michael
            Dhara Buch
                        Hello,
                  Hi Dhara,
                        I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
                        opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option.
                        I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol with this
uncompressed
            file, my CPU
                        type gets wrongly
                        identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring doesn't become
possible.
                  You can test the CPU identification by running `ophelp -r` which should
                  $ ophelp -r
                  Intel Skylake microarchitecture
                  What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
                  the newer processors. Consider using the latest OProfile 1.1. It might not
                  fit you if you need the legacy opcontrol-based profiling mode (which was
                  removed from 1.0 and above), but since you probably want to use the CPU
                  hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
                  well.
                  Regards,
                  Michael
                        I would be thankful if anybody can guide me to solve this problem.
                        Dhara Buch
dhara buch
2017-03-03 12:31:49 UTC
Permalink
Raw Message
Hello,

I downloaded the patch suggested by you, which was for perf_event_intel.c
file.

Although I did not build kernel by source, but I downloaded the source by
the following command:

*git clone git://kernel.ubuntu.com/ubuntu/ubuntu-wily.git
<http://kernel.ubuntu.com/ubuntu/ubuntu-wily.git>* (as the release name
ius wily)

In ubuntu-wily, I studied the source code of
/arch/x86/kernel/cpu/perf_event_intel.c
file where I found the following code in intel_pmu_init function:






































* case 61: /* 14nm Broadwell Core-M */ case 86: /* 14nm Broadwell Xeon
D */ case 71: /* 14nm Broadwell + GT3e (Intel Iris Pro graphics) */
case 79: /* 14nm Broadwell Server */ x86_pmu.late_ack = true;
memcpy(hw_cache_event_ids, hsw_hw_cache_event_ids,
sizeof(hw_cache_event_ids)); memcpy(hw_cache_extra_regs,
hsw_hw_cache_extra_regs, sizeof(hw_cache_extra_regs)); /*
L3_MISS_LOCAL_DRAM is BIT(26) in Broadwell */
hw_cache_extra_regs[C(LL)][C(OP_READ)][C(RESULT_MISS)] = HSW_DEMAND_READ
| BDW_L3_MISS|HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(LL)][C(OP_WRITE)][C(RESULT_MISS)] =
HSW_DEMAND_WRITE|BDW_L3_MISS|
HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(NODE)][C(OP_READ)][C(RESULT_ACCESS)] =
HSW_DEMAND_READ|
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM;
hw_cache_extra_regs[C(NODE)][C(OP_WRITE)][C(RESULT_ACCESS)] =
HSW_DEMAND_WRITE|
BDW_L3_MISS_LOCAL|HSW_SNOOP_DRAM; intel_pmu_lbr_init_hsw();
x86_pmu.event_constraints = intel_bdw_event_constraints;
x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
x86_pmu.extra_regs = intel_snbep_extra_regs; x86_pmu.pebs_aliases =
intel_pebs_aliases_snb; /* all extra regs are per-cpu when HT is on
*/ x86_pmu.flags |= PMU_FL_HAS_RSP_1; x86_pmu.flags |=
PMU_FL_NO_HT_SHARING; x86_pmu.hw_config = hsw_hw_config;
x86_pmu.get_event_constraints = hsw_get_event_constraints;
x86_pmu.cpu_events = hsw_events_attrs; x86_pmu.limit_period =
bdw_limit_period; pr_cont("Broadwell events, "); break;*


*From the above code, I guess that this version supports model no. 61.
Hence, I build the kernel using the downloaded source.*


*While giving dpkg -i linux-4.2.0*.deb command,*


* I removed all the files (initrd, vmlinux,config, abi and Systmap) for
the current version. I also removed links from root /.*


*The execution of dpkg command was proper and it generated new files for
which the previous copies were removed.*



*I rebooted the system, still the same error is encountered.*


*Is there any step which is missed for kernel rebuilding?*

*Thanks*
Post by Michael Petlan
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
Date: Tue Feb 17 18:18:05 2015 -0800
perf/x86/intel: Add Broadwell core support
That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).
You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.
The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.
You might try to update to some newer kernel to solve it.
It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.
Michael
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.
git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux, not Xen . Due
to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
I installed oprofile-1.1.0. When I executed ophelp -r
command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
Then I executed operf command without any option, but it gave
ou
Your kernel's performance event subsystem does not support
your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
3,737,940 cycles
0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
What is the solution?
Thank y
On Tue, Feb 28, 2017 at 12:40 PM, dhara buch <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
I am using i7 core processor. When I executed
ophelp -r, the displayed CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol
--vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed
to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am
also not much clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on
Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which
requires uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the
present vmlinuz with extract-vmlinux script. The file gts uncompressed,but
when I init opcontrol with this
uncompressed
file, my CPU
type gets wrongly
identified. Hence, although the
hardware events are supported by the processor, 'timer' mode gets set and
event monitoring doesn't become
possible.
You can test the CPU identification by
running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is
pretty old, it might not support
the newer processors. Consider using the
latest OProfile 1.1. It might not
fit you if you need the legacy
opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you
probably want to use the CPU
hardware events, I guess, operf-mode (and
oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can
guide me to solve this problem.
Dhara Buch
dhara buch
2017-03-04 13:26:53 UTC
Permalink
Raw Message
Hello,

In continuity of my previous mail, I would like to add that, after getting
failure in rebuilding existing kernel , I downloaded source of latest
linux-4.10.1 also.

While trying to install it i encountered :

REPORTING_BUGS not found error:

Can you please help to solve this issue?

Thanking you,

Dhara Buch
Post by Michael Petlan
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
Date: Tue Feb 17 18:18:05 2015 -0800
perf/x86/intel: Add Broadwell core support
That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).
You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.
The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.
You might try to update to some newer kernel to solve it.
It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.
Michael
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.
git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux, not Xen . Due
to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
I installed oprofile-1.1.0. When I executed ophelp -r
command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
Then I executed operf command without any option, but it gave
ou
Your kernel's performance event subsystem does not support
your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
3,737,940 cycles
0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
What is the solution?
Thank y
On Tue, Feb 28, 2017 at 12:40 PM, dhara buch <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
I am using i7 core processor. When I executed
ophelp -r, the displayed CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol
--vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed
to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am
also not much clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on
Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which
requires uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the
present vmlinuz with extract-vmlinux script. The file gts uncompressed,but
when I init opcontrol with this
uncompressed
file, my CPU
type gets wrongly
identified. Hence, although the
hardware events are supported by the processor, 'timer' mode gets set and
event monitoring doesn't become
possible.
You can test the CPU identification by
running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is
pretty old, it might not support
the newer processors. Consider using the
latest OProfile 1.1. It might not
fit you if you need the legacy
opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you
probably want to use the CPU
hardware events, I guess, operf-mode (and
oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can
guide me to solve this problem.
Dhara Buch
Michael Petlan
2017-03-06 13:55:30 UTC
Permalink
Raw Message
Hi Dhara,

from all the mails and our investigation, I think that OProfile,
your kernel version and your machine should be all OK. Thus, I
would guess that the problem is in Xen virtualization, which I
don't have any experience with, so I cannot help more. I have
used OProfile/perf/PMU HW events on QEMU/KVM guests and bare
metal boxes only. Thus I don't know what else to advise, I am
sorry.

Regards,
Michael
Post by dhara buch
Hello,
In continuity of my previous mail, I would like to add that, after getting failure in rebuilding existing kernel , I downloaded source of latest linux-4.10.1 also.
Can you please help to solve this issue?
Thanking you,
Dhara Buch
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
Date:   Tue Feb 17 18:18:05 2015 -0800
    perf/x86/intel: Add Broadwell core support
That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).
You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.
The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.
You might try to update to some newer kernel to solve it.
It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.
Michael
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux, not Xen . Due to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
            I installed oprofile-1.1.0. When I executed ophelp -r command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
      This is correct. The CPU has been detected correctly.
             
            ou
            Your kernel's performance event subsystem does not support your processor type.
      It looks like the VM guest has no access to the HW counters.
      Xen should be able to support it, however, I don't have any
      experience with Xen, thus nor with running OProfile there.
      Google says that you need to boot with 'vpmu=1'. Or try to
      search for "enable PMU in Xen guests" or similar.
      $ ocount ls
      Events were actively counted for 2669610 nanoseconds.
              Event                   Count                    % time counted
              cpu_clk_unhalted        3,982,864                100.00
      or using perf (linux-tools package), by
      $ perf stat -e cycles ls
               3,737,940      cycles
             0.013856521 seconds time elapsed
      I think this should work without any necessary patches if
      you enable PMU for the guest.
      Cheers,
      Michael
            What is the solution?
            Thank y
                  ---------- Forwarded message ----------
                  Date: Tue, Feb 28, 2017 at 12:00 AM
                  Subject: Re: Regarding vmlinux file for opcontrol --init
                        Hello,
                        Thanks a lot for the prompt reply.
                  Hi, you're welcome. Please do Reply-To-All to make sure it all
                  might appreciate the list history for solving similar problems
                  in future.
                        I am using i7 core processor. When I executed ophelp -r, the displayed CPU type was  'Intel Architectural Perfmon'.
                  The "Core i7" is too generic nomenclature. Could you please send
                  the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
                  Vendor ID:             GenuineIntel
                  CPU family:            6
                  Model:                 78
                        Afterwards, when I execute opcontrol --vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed to 'CPU with timer
Interrupt'.
                        The problem would be in uncompressed file? I am also not much clear about the proper way to get vmlinux from vmlinuz file.
                  I think you decompressed the file correctly. However, this does
                  not affect the CPU identification/understanding.
                  You can even skip vmlinux by using "--no-vmlinux" switch with
                  opcontrol. That will mark all the samples captured in kernel as
                  "no-vmlinux" and no vmlinux file is needed. However, this is no
                  good if you want to profile kernelspace.
                  Your problem is that your CPU is not identified by OProfile.
                  If you send me the `lscpu` output or the /proc/cpuinfo file
                  contents, I might figure out why.
                  However, it is very probable, that your CPU is supported by the
                  latest OProfile 1.1 and I encourage you to try that one instead.
                  ------------
                  There are two modes oprofile knows, let's call them "opcontrol-mode"
                  and "operf-mode".
                  --
                  1) "opcontrol-mode" is obsolete and consists of a kernel module,
                  a profiling daemon and a controller (opcontrol). By this controller,
                  you signal the profiling daemon to start/stop/reset profiling, etc.
                  The event sources can be either HW events or TIMER interrupt. The
                  TIMER interrupt is a fallback used by the daemon when HW events are
                  not detected. They are not detected when the CPU is unknown or not
                  supported. It might be also totally different architecture which
                  does not support any HW events, or, the HW events might be disabled
                  (e.g. you are running a virtual machine and the hypervisor does not
                  support/enable that for its guests).
                  The "TIMER interrupts" is a software-emulated event that is used
                  when the HW events are simply not available.
                  Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
                  mode". So using "TIMER interrupts" might be a reason why a user might
                  want to stick with this legacy "opcontrol-mode".
                  The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
                  the latest OProfile that supports it.
                  --
                  2) "operf-mode" is far better replacement for the previous mode. It
                  does not need any daemon and kernel module, the usage is much more
                  simple and it has lots of other advantages.
                  Basically, the only disadvantage is that it does NOT support the
                  TIMER interrupts fallback. Thus, when the HW events are not enabled/
                  detected/usable/supported/etc, you cannot fallback to the TIMER mode.
                  If you do not want to use the TIMER mode, there is basically no
                  reason for not using "operf-mode" instead, thus there is nothing to
                  be lost by updating to oprofile-1.1.
                  --------------------
                  So, I recommend to update to the latest OProfile and try out the
                  1) `ophelp -r` should still test the CPU identification
                  I believe, your CPU will be supported after updating, but I cannot
                  be sure without knowing the model/family numbers.
                  2) `ocount ls` should report some numbers (this tests whether the
                  HW events can be used).
                  3) `ophelp | less` will print all the HW events available to you
                  operf ls
                  opreport
                  operf -s --vmlinux /your/path/to/vmlinux
                  # wait here for a while
                  ^C
                  opreport
                  ------------------------
                  Hope it helps.
                  Michael
                        Dhara Buch
                                    Hello,
                              Hi Dhara,
                                    I have installed Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
                                    opcontrol --init command, which requires uncompressed vmlinux file with --vmlinux option.
                                    I have tried to uncompress the present vmlinuz with extract-vmlinux script. The file gts uncompressed,but when I init opcontrol
with this
            uncompressed
                        file, my CPU
                                    type gets wrongly
                                    identified. Hence, although the hardware events are supported by the processor, 'timer' mode gets set and event monitoring
doesn't become
            possible.
                              You can test the CPU identification by running `ophelp -r` which should
                              $ ophelp -r
                              Intel Skylake microarchitecture
                              What is your CPU type? OProfile 0.9.9 is pretty old, it might not support
                              the newer processors. Consider using the latest OProfile 1.1. It might not
                              fit you if you need the legacy opcontrol-based profiling mode (which was
                              removed from 1.0 and above), but since you probably want to use the CPU
                              hardware events, I guess, operf-mode (and oprofile-1.1) should serve you
                              well.
                              Regards,
                              Michael
                                    I would be thankful if anybody can guide me to solve this problem.
                                    Dhara Buch
dhara buch
2017-03-06 16:44:20 UTC
Permalink
Raw Message
Thanks a lot for your reply.

Considering Xen virtualization problem, if I plan to work with KVM, will it
work if I use KVM with Ubuntu only.

Is it necessary to go for redhat for HW events monitoring?

Regards
Post by Michael Petlan
Hi Dhara,
from all the mails and our investigation, I think that OProfile,
your kernel version and your machine should be all OK. Thus, I
would guess that the problem is in Xen virtualization, which I
don't have any experience with, so I cannot help more. I have
used OProfile/perf/PMU HW events on QEMU/KVM guests and bare
metal boxes only. Thus I don't know what else to advise, I am
sorry.
Regards,
Michael
Post by dhara buch
Hello,
In continuity of my previous mail, I would like to add that, after
getting failure in rebuilding existing kernel , I downloaded source of
latest linux-4.10.1 also.
Can you please help to solve this issue?
Thanking you,
Dhara Buch
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
Date: Tue Feb 17 18:18:05 2015 -0800
perf/x86/intel: Add Broadwell core support
That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).
You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.
The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.
You might try to update to some newer kernel to solve it.
It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.
Michael
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.
git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU
driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux,
not Xen . Due to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
On Tue, Feb 28, 2017 at 6:20 PM, Michael Petlan <
I installed oprofile-1.1.0. When I executed
ophelp -r command, it gave me output as 'Intel Broadwell Microarchitecture
as output'.
This is correct. The CPU has been detected correctly.
Then I executed operf command without any option,
ou
Your kernel's performance event subsystem does
not support your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count
% time counted
cpu_clk_unhalted 3,982,864
100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
3,737,940 cycles
0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
What is the solution?
Thank y
On Tue, Feb 28, 2017 at 12:40 PM, dhara buch <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All
to make sure it all
e.net --> others
might appreciate the list history for
solving similar problems
in future.
I am using i7 core processor. When I
executed ophelp -r, the displayed CPU type was 'Intel Architectural
Perfmon'.
The "Core i7" is too generic nomenclature.
Could you please send
the output of `lscpu` or attach
/proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol
--vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed
to 'CPU with timer
Interrupt'.
The problem would be in uncompressed
file? I am also not much clear about the proper way to get vmlinux from
vmlinuz file.
I think you decompressed the file
correctly. However, this does
not affect the CPU
identification/understanding.
You can even skip vmlinux by using
"--no-vmlinux" switch with
opcontrol. That will mark all the samples
captured in kernel as
"no-vmlinux" and no vmlinux file is needed.
However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not
identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU
is supported by the
latest OProfile 1.1 and I encourage you to
try that one instead.
------------
There are two modes oprofile knows, let's
call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and
consists of a kernel module,
a profiling daemon and a controller
(opcontrol). By this controller,
you signal the profiling daemon to
start/stop/reset profiling, etc.
The event sources can be either HW events
or TIMER interrupt. The
TIMER interrupt is a fallback used by the
daemon when HW events are
not detected. They are not detected when
the CPU is unknown or not
supported. It might be also totally
different architecture which
does not support any HW events, or, the HW
events might be disabled
(e.g. you are running a virtual machine and
the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a
software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE
NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be
a reason why a user might
want to stick with this legacy
"opcontrol-mode".
The "opcontrol-mode" has been removed from
OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement
for the previous mode. It
does not need any daemon and kernel module,
the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it
does NOT support the
TIMER interrupts fallback. Thus, when the
HW events are not enabled/
detected/usable/supported/etc, you cannot
fallback to the TIMER mode.
If you do not want to use the TIMER mode,
there is basically no
reason for not using "operf-mode" instead,
thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest
OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after
updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers
(this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW
events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
On Mon, Feb 27, 2017 at 10:24 PM,
Hello,
Hi Dhara,
I have installed
Oprofile-0.9.9 on Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command,
which requires uncompressed vmlinux file with --vmlinux option.
I have tried to
uncompress the present vmlinuz with extract-vmlinux script. The file gts
uncompressed,but when I init opcontrol
with this
uncompressed
file, my CPU
type gets wrongly
identified. Hence,
although the hardware events are supported by the processor, 'timer' mode
gets set and event monitoring
doesn't become
possible.
You can test the CPU
identification by running `ophelp -r` which should
print what OProfile thinks your
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile
0.9.9 is pretty old, it might not support
the newer processors. Consider
using the latest OProfile 1.1. It might not
fit you if you need the legacy
opcontrol-based profiling mode (which was
removed from 1.0 and above),
but since you probably want to use the CPU
hardware events, I guess,
operf-mode (and oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if
anybody can guide me to solve this problem.
Dhara Buch
Michael Petlan
2017-03-06 17:06:47 UTC
Permalink
Raw Message
Post by dhara buch
Thanks a lot for your reply.
Considering Xen virtualization problem, if I plan to work with KVM, will it work if I use KVM with Ubuntu only.
Is it necessary to go for redhat for HW events monitoring?
It should work with Ubuntu, but I have run that myself on RHEL/Fedora
only, so far.

Please refer to [1] regarding to enabling PMU support there.

Cheers,
Michael

[1] https://sourceforge.net/p/oprofile/mailman/message/35645458/
Post by dhara buch
Regards
Hi Dhara,
from all the mails and our investigation, I think that OProfile,
your kernel version and your machine should be all OK. Thus, I
would guess that the problem is in Xen virtualization, which I
don't have any experience with, so I cannot help more. I have
used OProfile/perf/PMU HW events on QEMU/KVM guests and bare
metal boxes only. Thus I don't know what else to advise, I am
sorry.
Regards,
Michael
Hello,
In continuity of my previous mail, I would like to add that, after getting failure in rebuilding existing kernel , I downloaded source of latest linux-4.10.1 also.
Can you please help to solve this issue?
Thanking you,
Dhara Buch
dhara buch
2017-03-07 17:25:03 UTC
Permalink
Raw Message
Hi,

Although now I will try with Fedora+KVM, in my existing ssetup (Uvuntu+Xen)
I tried to change cpu mode as per the way, you have shown in previous link.

I have installed libvirt-bin for ubuntu but libvirtd service is not getting
started. It gives an error like:
libvirt service not found. no such file or directory.

Any installation is missing?

Thanking you,

Dhara Buch
Post by Michael Petlan
Post by dhara buch
Thanks a lot for your reply.
Considering Xen virtualization problem, if I plan to work with KVM, will
it work if I use KVM with Ubuntu only.
Is it necessary to go for redhat for HW events monitoring?
It should work with Ubuntu, but I have run that myself on RHEL/Fedora
only, so far.
Please refer to [1] regarding to enabling PMU support there.
Cheers,
Michael
[1] https://sourceforge.net/p/oprofile/mailman/message/35645458/
Post by dhara buch
Regards
Hi Dhara,
from all the mails and our investigation, I think that OProfile,
your kernel version and your machine should be all OK. Thus, I
would guess that the problem is in Xen virtualization, which I
don't have any experience with, so I cannot help more. I have
used OProfile/perf/PMU HW events on QEMU/KVM guests and bare
metal boxes only. Thus I don't know what else to advise, I am
sorry.
Regards,
Michael
Hello,
In continuity of my previous mail, I would like to add that,
after getting failure in rebuilding existing kernel , I downloaded source
of latest linux-4.10.1 also.
Can you please help to solve this issue?
Thanking you,
Dhara Buch
Michael Petlan
2017-03-07 23:21:06 UTC
Permalink
Raw Message
Hi,

I am very far from being an expert in virtualization. I am just sharing
what works for me. The solution I described is QEMU/KVM-only.

The configuration (XML snippet) is set on the host per guests. When a
guest is configured with <cpu mode='host-passthrough'/>, it should be
able to use the host's PMU from within the guest.

It is not important what is running on the guest (fedora, ubuntu) at
all, and, it is probably not important what is running on the host either
(fedora/ubuntu).

I did not get from your mail whether you installed the libvirt-bin on
guest or on host. However, all the configuration from the link I sent
is done on the _host_ (QEMU/KVM host, which is just a usual Linux box).

I don't know what are your other needs/limitations, but...

Let's suppose you have a Broadwell bare metal machine which you don't
really care which OS it is running. Having that, I would install Fedora
there, then I would try out oprofile there (it is available within the
repositories (`dnf install oprofile`). If this works (it should), then
I would follow a tutorial how to set up a QEMU/KVM guest on Fedora and
install anything you want into that guest.

Then, on the host, change the settings of the guest as described in [1]
and try the latest oprofile in the guest.

This should work.

However, wrt Xen, google says, that for enabling PMU within guests, you
need to boot with 'vpmu=1' option [2]. Just saying.

Michael

[1] https://sourceforge.net/p/oprofile/mailman/message/35645458/
[2] https://lwn.net/Articles/566159/
Hi,
Although now I will try with Fedora+KVM, in my existing ssetup (Uvuntu+Xen) I tried to change cpu mode as per the
way, you have shown in previous link.
libvirt service not found. no such file or directory.
Any installation is missing?
Thanking you,
Dhara Buch
Thanks a lot for your reply.
Considering Xen virtualization problem, if I plan to work with KVM, will it work if I use KVM
with Ubuntu only.
Is it necessary to go for redhat for HW events monitoring?
It should work with Ubuntu, but I have run that myself on RHEL/Fedora
only, so far.
Please refer to [1] regarding to enabling PMU support there.
Cheers,
Michael
[1] https://sourceforge.net/p/oprofile/mailman/message/35645458/
Regards
      Hi Dhara,
      from all the mails and our investigation, I think that OProfile,
      your kernel version and your machine should be all OK. Thus, I
      would guess that the problem is in Xen virtualization, which I
      don't have any experience with, so I cannot help more. I have
      used OProfile/perf/PMU HW events on QEMU/KVM guests and bare
      metal boxes only. Thus I don't know what else to advise, I am
      sorry.
      Regards,
      Michael
            Hello,
            In continuity of my previous mail, I would like to add that, after getting
failure in rebuilding existing kernel , I downloaded source of latest linux-4.10.1 also.
            Can you please help to solve this issue?
            Thanking you,
            Dhara Buch
dhara buch
2017-03-11 17:24:10 UTC
Permalink
Raw Message
Hello,

I have installed Fedora 25 and qemu/kvm.Now I am trying to create a VM with
virtual machine manager, but getting following error:

internal error: process exited wile connecting to mirror:......Permission
Denied.

I tried the same from root login also, but getting the same error.

Where the problem may be?

Thanking you,

Dhara Buch
Post by Michael Petlan
Hi,
Broadwell PMU support was added to linux kernel by commit
91f1b70582c62576f429cf78d53751c66677553d [1] --> you might
commit 91f1b70582c62576f429cf78d53751c66677553d
Date: Tue Feb 17 18:18:05 2015 -0800
perf/x86/intel: Add Broadwell core support
That patch came into linux v4.1, so your Ubuntu 15.10 should
contain it (there should be 4.2 or higher).
You're right, PMU seems not to be initialized correctly.
Kernel needs to be built with CONFIG_PERF_EVENTS=y, however,
I expect that your one is, otherwise it would not attempt to
init the PMU.
The log really looks that your kernel does not know what to
do with '61' (Broadwell). So in case the kernel is new enough
to support it, then something is probably broken.
You might try to update to some newer kernel to solve it.
It is also possible (but does not look very probable), that
the message in log is caused by Xen, but I think it would
look different in such case (unsuccessful init instead of
"no PMU driver")... But this is what I think, I am not sure.
Michael
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.
git/commit/?id=91f1b70582c62576f429cf78d53751c66677553d
Hi,
Performance Events: unsupported p6 CPU model he 61 no PMU driver, software events only.
61 is my CPU model No.
As per my study, if I am not wrong this is given by linux, not Xen . Due
to this probably PMU is not getting enabled.
Can you help me out in solving this?
Thanks
I installed oprofile-1.1.0. When I executed ophelp -r
command, it gave me output as 'Intel Broadwell Microarchitecture as output'.
This is correct. The CPU has been detected correctly.
Then I executed operf command without any option, but it gave
ou
Your kernel's performance event subsystem does not support
your processor type.
It looks like the VM guest has no access to the HW counters.
Xen should be able to support it, however, I don't have any
experience with Xen, thus nor with running OProfile there.
Google says that you need to boot with 'vpmu=1'. Or try to
search for "enable PMU in Xen guests" or similar.
$ ocount ls
Events were actively counted for 2669610 nanoseconds.
Event Count % time counted
cpu_clk_unhalted 3,982,864 100.00
or using perf (linux-tools package), by
$ perf stat -e cycles ls
3,737,940 cycles
0.013856521 seconds time elapsed
I think this should work without any necessary patches if
you enable PMU for the guest.
Cheers,
Michael
What is the solution?
Thank y
On Tue, Feb 28, 2017 at 12:40 PM, dhara buch <
---------- Forwarded message ----------
Date: Tue, Feb 28, 2017 at 12:00 AM
Subject: Re: Regarding vmlinux file for opcontrol --init
Hello,
Thanks a lot for the prompt reply.
Hi, you're welcome. Please do Reply-To-All to make sure it all
might appreciate the list history for solving similar problems
in future.
I am using i7 core processor. When I executed
ophelp -r, the displayed CPU type was 'Intel Architectural Perfmon'.
The "Core i7" is too generic nomenclature. Could you please send
the output of `lscpu` or attach /proc/cpuinfo (one core is enough)?
Vendor ID: GenuineIntel
CPU family: 6
Model: 78
Afterwards, when I execute opcontrol
--vmlinux=(uncompressed form of vmlinuz) command, the CPU type gets changed
to 'CPU with timer Interrupt'.
The problem would be in uncompressed file? I am
also not much clear about the proper way to get vmlinux from vmlinuz file.
I think you decompressed the file correctly. However, this does
not affect the CPU identification/understanding.
You can even skip vmlinux by using "--no-vmlinux" switch with
opcontrol. That will mark all the samples captured in kernel as
"no-vmlinux" and no vmlinux file is needed. However, this is no
good if you want to profile kernelspace.
Your problem is that your CPU is not identified by OProfile.
If you send me the `lscpu` output or the /proc/cpuinfo file
contents, I might figure out why.
However, it is very probable, that your CPU is supported by the
latest OProfile 1.1 and I encourage you to try that one instead.
------------
There are two modes oprofile knows, let's call them "opcontrol-mode"
and "operf-mode".
--
1) "opcontrol-mode" is obsolete and consists of a kernel module,
a profiling daemon and a controller (opcontrol). By this controller,
you signal the profiling daemon to start/stop/reset profiling, etc.
The event sources can be either HW events or TIMER interrupt. The
TIMER interrupt is a fallback used by the daemon when HW events are
not detected. They are not detected when the CPU is unknown or not
supported. It might be also totally different architecture which
does not support any HW events, or, the HW events might be disabled
(e.g. you are running a virtual machine and the hypervisor does not
support/enable that for its guests).
The "TIMER interrupts" is a software-emulated event that is used
when the HW events are simply not available.
Also note, that the TIMER interrupts ARE NOT SUPPORTED in the "operf-
mode". So using "TIMER interrupts" might be a reason why a user might
want to stick with this legacy "opcontrol-mode".
The "opcontrol-mode" has been removed from OProfile 1.0, so 0.9.9 is
the latest OProfile that supports it.
--
2) "operf-mode" is far better replacement for the previous mode. It
does not need any daemon and kernel module, the usage is much more
simple and it has lots of other advantages.
Basically, the only disadvantage is that it does NOT support the
TIMER interrupts fallback. Thus, when the HW events are not enabled/
detected/usable/supported/etc, you cannot fallback to the TIMER mode.
If you do not want to use the TIMER mode, there is basically no
reason for not using "operf-mode" instead, thus there is nothing to
be lost by updating to oprofile-1.1.
--------------------
So, I recommend to update to the latest OProfile and try out the
1) `ophelp -r` should still test the CPU identification
I believe, your CPU will be supported after updating, but I cannot
be sure without knowing the model/family numbers.
2) `ocount ls` should report some numbers (this tests whether the
HW events can be used).
3) `ophelp | less` will print all the HW events available to you
operf ls
opreport
operf -s --vmlinux /your/path/to/vmlinux
# wait here for a while
^C
opreport
------------------------
Hope it helps.
Michael
Dhara Buch
On Mon, Feb 27, 2017 at 10:24 PM, Michael Petlan <
Hello,
Hi Dhara,
I have installed Oprofile-0.9.9 on
Ubuntu 15.10. I try to init oprofile with'
opcontrol --init command, which
requires uncompressed vmlinux file with --vmlinux option.
I have tried to uncompress the
present vmlinuz with extract-vmlinux script. The file gts uncompressed,but
when I init opcontrol with this
uncompressed
file, my CPU
type gets wrongly
identified. Hence, although the
hardware events are supported by the processor, 'timer' mode gets set and
event monitoring doesn't become
possible.
You can test the CPU identification by
running `ophelp -r` which should
$ ophelp -r
Intel Skylake microarchitecture
What is your CPU type? OProfile 0.9.9 is
pretty old, it might not support
the newer processors. Consider using the
latest OProfile 1.1. It might not
fit you if you need the legacy
opcontrol-based profiling mode (which was
removed from 1.0 and above), but since you
probably want to use the CPU
hardware events, I guess, operf-mode (and
oprofile-1.1) should serve you
well.
Regards,
Michael
I would be thankful if anybody can
guide me to solve this problem.
Dhara Buch
Loading...