From: Kevin V. W. <va...@sa...> - 2013-03-28 21:39:07
|
Hello, I'm new to OProfile and am running into the "Your kernel's Performance Events Subsystem does not support your processor type." message when running operf. I built the 2.6.34.14 kernel and selected OProfile support when I configured the kernel: CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_EVENTS=y CONFIG_OPROFILE=y # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set CONFIG_HAVE_OPROFILE=y I also built oprofile-0.9.8 using --with-kernel to point to the kernel's source tree. I had to make a symlink to asm->asm_generic in the kernel's include dir. I also had to remove references to PERF_RECORD_MISC_GUEST_KERNEL and to PERF_RECORD_MISC_GUEST_USER in libperf_events/operf_utils.cpp since these aren't in 2.6.34. # diff operf_utils.cpp operf_utils.cpp.orig 734a735,740 > case PERF_RECORD_MISC_GUEST_KERNEL: > domain = "guest OS"; > break; > case PERF_RECORD_MISC_GUEST_USER: > domain = "guest user"; > break; I'm not sure why operf says my kernel's perf_events doesn't support my processor type (AMD Opteron 6220). Is it true that I can't use operf on this kernel/architecture? What I am missing here? -- Kevin Van Workum, PhD Sabalcore Computing Inc. "Where Data Becomes Discovery" http://www.sabalcore.com 877-492-8027 ext. 11 -- |
From: Maynard J. <may...@us...> - 2013-03-28 23:07:20
|
On 03/28/2013 04:31 PM, Kevin Van Workum wrote: > Hello, > > I'm new to OProfile and am running into the "Your kernel's Performance Events Subsystem does not support your processor type." message when running operf. > > I built the 2.6.34.14 kernel and selected OProfile support when I configured the kernel: > > CONFIG_HAVE_PERF_EVENTS=y > CONFIG_PERF_EVENTS=y > CONFIG_OPROFILE=y > # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set > CONFIG_HAVE_OPROFILE=y > > I also built oprofile-0.9.8 using --with-kernel to point to the kernel's source tree. I had to make a symlink to asm->asm_generic in the kernel's include dir. I also had to remove references to PERF_RECORD_MISC_GUEST_KERNEL and to PERF_RECORD_MISC_GUEST_USER in libperf_events/operf_utils.cpp since these aren't in 2.6.34. Yeah, that bug is fixed upstream, post-0.9.8. > > # diff operf_utils.cpp operf_utils.cpp.orig > 734a735,740 >> case PERF_RECORD_MISC_GUEST_KERNEL: >> domain = "guest OS"; >> break; >> case PERF_RECORD_MISC_GUEST_USER: >> domain = "guest user"; >> break; > > I'm not sure why operf says my kernel's perf_events doesn't support my processor type (AMD Opteron 6220). Is it true that I can't use operf on this kernel/architecture? What I am missing here? *Suravee*, as our our AMD expert, can you help Kevin with this question. The error message states very clearly that the kernel doesn't have perf_events support for the 6220. The 6220 was released in Nov 2011, and the base 2.6.34 kernel was released about a year before that. What kernel version would he need? *Kevin*, is there a reason why you're using such an old kernel? -Maynard > > -- > Kevin Van Workum, PhD > Sabalcore Computing Inc. > "Where Data Becomes Discovery" > http://www.sabalcore.com > 877-492-8027 ext. 11 > > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Suravee S. <sur...@am...> - 2013-03-28 23:45:39
|
Hi, This is family15h which should have already supported in the 2.6.34 kernel w/ the OProfile-0.9.8. Could you please provide the output from "dmesg"? Thank you, Suravee. On 3/28/2013 4:31 PM, Kevin Van Workum wrote: > Hello, > > I'm new to OProfile and am running into the "Your kernel's Performance > Events Subsystem does not support your processor type." message when > running operf. > > I built the 2.6.34.14 kernel and selected OProfile support when I > configured the kernel: > > CONFIG_HAVE_PERF_EVENTS=y > CONFIG_PERF_EVENTS=y > CONFIG_OPROFILE=y > # CONFIG_OPROFILE_EVENT_MULTIPLEX is not set > CONFIG_HAVE_OPROFILE=y > > I also built oprofile-0.9.8 using --with-kernel to point to the > kernel's source tree. I had to make a symlink to asm->asm_generic in > the kernel's include dir. I also had to remove references to > PERF_RECORD_MISC_GUEST_KERNEL and to PERF_RECORD_MISC_GUEST_USER in > libperf_events/operf_utils.cpp since these aren't in 2.6.34. > > # diff operf_utils.cpp operf_utils.cpp.orig > 734a735,740 > > case PERF_RECORD_MISC_GUEST_KERNEL: > > domain = "guest OS"; > > break; > > case PERF_RECORD_MISC_GUEST_USER: > > domain = "guest user"; > > break; > > I'm not sure why operf says my kernel's perf_events doesn't support my > processor type (AMD Opteron 6220). Is it true that I can't use operf > on this kernel/architecture? What I am missing here? > > -- > Kevin Van Workum, PhD > Sabalcore Computing Inc. > "Where Data Becomes Discovery" > http://www.sabalcore.com > 877-492-8027 ext. 11 > |
From: Suthikulpanit, S. <Sur...@am...> - 2013-04-01 05:44:00
|
Kevin, I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information: - What is the Linux distro? - What was the operf command you were using? Thank you, Suravee From: Kevin Van Workum [mailto:va...@sa...] Sent: Friday, March 29, 2013 11:15 AM To: Suthikulpanit, Suravee Cc: opr...@li... Subject: Re: support for AMD Opteron 6220 on 2.6.34 kernel On Thu, Mar 28, 2013 at 7:30 PM, Suravee Suthikulanit <sur...@am...<mailto:sur...@am...>> wrote: Hi, This is family15h which should have already supported in the 2.6.34 kernel w/ the OProfile-0.9.8. Could you please provide the output from "dmesg"? dmesg is attached. Thanks. [http://www.sabalcore.com/images/Sabalcore_Computing.png] |
From: Kevin V. W. <va...@sa...> - 2013-04-01 11:20:09
|
On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee < Sur...@am...> wrote: > Kevin,**** > > ** ** > > I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and > it seems to work fine. Could you provide me with some more information:** > ** > > ** ** > > **- **What is the Linux distro? > Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? > **** > > **- **What was the operf command you were using? > operf --help Thanks for your help. -- |
From: Maynard J. <may...@us...> - 2013-04-01 14:48:13
|
On 04/01/2013 06:19 AM, Kevin Van Workum wrote: > > On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: > > Kevin,____ > > __ __ > > I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ > > __ __ > > __- __What is the Linux distro? > > > Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. Another instructive experiment would be to build and install the perf tool on your system. Since Centos 5.5 is too old of a distro to include the perf package, you'll need to go into your 2.6.34.14 source tree under the tools/perf directory and build the perf tool yourself. You might have some difficulty building perf as your Centos distro may not be able to satisfy all of its dependencies. But if you can successfully build/install it, then just try 'perf record ls' as a simple test. -Maynard > > ____ > > __- __What was the operf command you were using? > > > operf --help > > Thanks for your help. > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Suravee S. <sur...@am...> - 2013-04-01 15:48:35
|
On 4/1/2013 9:47 AM, Maynard Johnson wrote: > On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >> >> Kevin,____ >> >> __ __ >> >> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >> >> __ __ >> >> __- __What is the Linux distro? >> >> >> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? > It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. > > As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. Kevin mentioned (on a separate thread when I pinged him for more information) that 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). > Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? Suravee > Another instructive experiment would be to build and install the perf tool on your system. Since Centos 5.5 is too old of a distro to include the perf package, you'll need to go into your 2.6.34.14 source tree under the tools/perf directory and build the perf tool yourself. You might have some difficulty building perf as your Centos distro may not be able to satisfy all of its dependencies. But if you can successfully build/install it, then just try 'perf record ls' as a simple test. > > -Maynard >> ____ >> >> __- __What was the operf command you were using? >> >> >> operf --help >> >> Thanks for your help. >> >> >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> >> >> >> _______________________________________________ >> oprofile-list mailing list >> opr...@li... >> https://lists.sourceforge.net/lists/listinfo/oprofile-list >> > |
From: Maynard J. <may...@us...> - 2013-04-01 16:52:41
|
On 04/01/2013 10:48 AM, Suravee Suthikulanit wrote: > On 4/1/2013 9:47 AM, Maynard Johnson wrote: >> On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >>> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >>> >>> Kevin,____ >>> >>> __ __ >>> >>> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >>> >>> __ __ >>> >>> __- __What is the Linux distro? >>> >>> >>> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? >> It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. >> >> As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. > Kevin mentioned (on a separate thread when I pinged him for more information) that > 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. > 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). > >> Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. > It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? Hi, Suravee, The failure is occurring as a result of calling _check_perf_events_cap(), which is *before* the call to get the cpu type. So it's the 'syscall(__NR_perf_event_open,...)' that's returning ENOENT. -Maynard > > Suravee >> Another instructive experiment would be to build and install the perf tool on your system. Since Centos 5.5 is too old of a distro to include the perf package, you'll need to go into your 2.6.34.14 source tree under the tools/perf directory and build the perf tool yourself. You might have some difficulty building perf as your Centos distro may not be able to satisfy all of its dependencies. But if you can successfully build/install it, then just try 'perf record ls' as a simple test. >> >> -Maynard >>> ____ >>> >>> __- __What was the operf command you were using? >>> >>> >>> operf --help >>> Thanks for your help. >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Own the Future-Intel® Level Up Game Demo Contest 2013 >>> Rise to greatness in Intel's independent game demo contest. >>> Compete for recognition, cash, and the chance to get your game >>> on Steam. $5K grand prize plus 10 genre and skill prizes. >>> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >>> >>> >>> >>> _______________________________________________ >>> oprofile-list mailing list >>> opr...@li... >>> https://lists.sourceforge.net/lists/listinfo/oprofile-list >>> >> > > |
From: Kevin V. W. <va...@sa...> - 2013-04-03 12:44:08
|
On Mon, Apr 1, 2013 at 12:51 PM, Maynard Johnson <may...@us...> wrote: > On 04/01/2013 10:48 AM, Suravee Suthikulanit wrote: >> On 4/1/2013 9:47 AM, Maynard Johnson wrote: >>> On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >>>> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >>>> >>>> Kevin,____ >>>> >>>> __ __ >>>> >>>> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >>>> >>>> __ __ >>>> >>>> __- __What is the Linux distro? >>>> >>>> >>>> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? >>> It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. >>> >>> As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. >> Kevin mentioned (on a separate thread when I pinged him for more information) that >> 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. >> 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). >> >>> Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. >> It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? > Hi, Suravee, > The failure is occurring as a result of calling _check_perf_events_cap(), which is *before* the call to get the cpu type. So it's the 'syscall(__NR_perf_event_open,...)' that's returning ENOENT. So is the verdict that this is an issue with the kernel version or with operf? -- |
From: Suthikulpanit, S. <Sur...@am...> - 2013-04-03 14:00:59
|
Kevin, Are you able to run profile as root? Suravee -------- Original message -------- From: Kevin Van Workum <va...@sa...> Date: To: Maynard Johnson <may...@us...> Cc: "Suthikulpanit, Suravee" <Sur...@am...>,opr...@li... Subject: Re: support for AMD Opteron 6220 on 2.6.34 kernel On Mon, Apr 1, 2013 at 12:51 PM, Maynard Johnson <may...@us...> wrote: > On 04/01/2013 10:48 AM, Suravee Suthikulanit wrote: >> On 4/1/2013 9:47 AM, Maynard Johnson wrote: >>> On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >>>> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >>>> >>>> Kevin,____ >>>> >>>> __ __ >>>> >>>> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >>>> >>>> __ __ >>>> >>>> __- __What is the Linux distro? >>>> >>>> >>>> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? >>> It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. >>> >>> As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. >> Kevin mentioned (on a separate thread when I pinged him for more information) that >> 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. >> 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). >> >>> Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. >> It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? > Hi, Suravee, > The failure is occurring as a result of calling _check_perf_events_cap(), which is *before* the call to get the cpu type. So it's the 'syscall(__NR_perf_event_open,...)' that's returning ENOENT. So is the verdict that this is an issue with the kernel version or with operf? -- |
From: Maynard J. <may...@us...> - 2013-04-03 14:29:39
|
On 04/03/2013 07:44 AM, Kevin Van Workum wrote: > On Mon, Apr 1, 2013 at 12:51 PM, Maynard Johnson <may...@us...> wrote: >> On 04/01/2013 10:48 AM, Suravee Suthikulanit wrote: >>> On 4/1/2013 9:47 AM, Maynard Johnson wrote: >>>> On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >>>>> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >>>>> >>>>> Kevin,____ >>>>> >>>>> __ __ >>>>> >>>>> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >>>>> >>>>> __ __ >>>>> >>>>> __- __What is the Linux distro? >>>>> >>>>> >>>>> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? >>>> It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. >>>> >>>> As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. >>> Kevin mentioned (on a separate thread when I pinged him for more information) that >>> 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. >>> 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). >>> >>>> Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. >>> It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? >> Hi, Suravee, >> The failure is occurring as a result of calling _check_perf_events_cap(), which is *before* the call to get the cpu type. So it's the 'syscall(__NR_perf_event_open,...)' that's returning ENOENT. > > So is the verdict that this is an issue with the kernel version or with operf? Kevin, I had suggested you try building/installing the 'perf' tool from the kernel source tree. I still think it would be helpful to know if perf would misbehave similarly to operf. I suspect it will. *Suravee*, you stated above (in your April 1 response) that you "tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine". What distro was installed on that test system of yours? Kevin's Centos 5.5 doesn't have native perf_events support, but since he built and installed kernel 2.6.34.14 and then built oprofile using the '--with-kernel' option, it should (theoretically) work OK. The error he's getting implies that the perf_event_open syscall is being executed, but the return value implies a lack of hardware support in the kernel -- which doesn't make sense, since you've already verified 2.6.34 supports this processor type. So what's the difference? I can't think of why the underlying distro would cause such a problem, but we can't rule out the possibility (since we have no other theories at the moment). -Maynard > |
From: Kevin V. W. <va...@sa...> - 2013-04-03 17:17:57
|
On Wed, Apr 3, 2013 at 10:25 AM, Maynard Johnson <may...@us...> wrote: > Kevin, I had suggested you try building/installing the 'perf' tool from the kernel source tree. I still think it would be helpful to know if perf would misbehave similarly to operf. I suspect it will. > I did as Maynard suggested and build the perf tool from the kernel source. It seems to work as expected. Here's the output running it as a normal user: $ perf record ls perf.data [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.001 MB perf.data (~50 samples) ] -- |
From: Suravee S. <sur...@am...> - 2013-04-03 15:23:40
|
On 4/3/2013 9:25 AM, Maynard Johnson wrote: > On 04/03/2013 07:44 AM, Kevin Van Workum wrote: >> On Mon, Apr 1, 2013 at 12:51 PM, Maynard Johnson <may...@us...> wrote: >>> On 04/01/2013 10:48 AM, Suravee Suthikulanit wrote: >>>> On 4/1/2013 9:47 AM, Maynard Johnson wrote: >>>>> On 04/01/2013 06:19 AM, Kevin Van Workum wrote: >>>>>> On Mon, Apr 1, 2013 at 1:43 AM, Suthikulpanit, Suravee <Sur...@am... <mailto:Sur...@am...>> wrote: >>>>>> >>>>>> Kevin,____ >>>>>> >>>>>> __ __ >>>>>> >>>>>> I have tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine. Could you provide me with some more information:____ >>>>>> >>>>>> __ __ >>>>>> >>>>>> __- __What is the Linux distro? >>>>>> >>>>>> >>>>>> Centos 5.5, glibc-2.5. Why would that be important? What distro did you use? >>>>> It might be instructive to see if profiling tools other than operf work for your processor type and distro/kernel version. >>>>> >>>>> As root user, try 'opcontrol --init' and then check the contents of /dev/oprofile/cpu_type. If the kernel has "legacy" oprofile support for family15h, you should see "x86-64/family15h" in the cpu_type file. But looking at the 2.6.34 kernel with the 2.6.34.14 patch applied, it does not appear to me that legacy oprofile is supported for family15h. >>>> Kevin mentioned (on a separate thread when I pinged him for more information) that >>>> 1. /dev/oprofile/cpu_type is "timer" which means the "legacy" oprofile driver doesn't support family15h. >>>> 2. I also check the kernel code and see that this is consistent (also same as what Maynard is reporting... Thanks). >>>> >>>>> Suravee's above claim that family15h *is* supported in this kernel may be in reference to the Performance Events Subsystem (aka "perf_events"), which operf uses. I don't know where in the 2.6.34.14 kernel source to look to know how to verify that claim. >>>> It should be supported with "operf". I did run "operf" on my family15h based system and it works ok for me. The user-space operf should be able to derive the correct processor information (from CPUID) isn't it? >>> Hi, Suravee, >>> The failure is occurring as a result of calling _check_perf_events_cap(), which is *before* the call to get the cpu type. So it's the 'syscall(__NR_perf_event_open,...)' that's returning ENOENT. >> So is the verdict that this is an issue with the kernel version or with operf? > Kevin, I had suggested you try building/installing the 'perf' tool from the kernel source tree. I still think it would be helpful to know if perf would misbehave similarly to operf. I suspect it will. > > *Suravee*, you stated above (in your April 1 response) that you "tried latest Oprofile (from the trunk) with the kernel-2.6.34 and it seems to work fine". What distro was installed on that test system of yours? Kevin's Centos 5.5 doesn't have native perf_events support, but since he built and installed kernel 2.6.34.14 and then built oprofile using the '--with-kernel' option, it should (theoretically) work OK. I am using Ubuntu-12.10 and I installed the 2.6.34.14. When I build oprofile with "--with-kernel" it doesn't even build "operf". > The error he's getting implies that the perf_event_open syscall is being executed, but the return value implies a lack of hardware support in the kernel -- which doesn't make sense, since you've already verified 2.6.34 supports this processor type. So what's the difference? I can't think of why the underlying distro would cause such a problem, but we can't rule out the possibility (since we have no other theories at the moment). I remember I vaguely that I used to run into issues in older kernels when trying to profile with non-root, and it had to do with /proc/sys/kernel/perf_event_paranoid. Suravee > > -Maynard > |
From: Kevin V. W. <va...@sa...> - 2013-04-03 16:53:14
|
On Wed, Apr 3, 2013 at 11:08 AM, Suravee Suthikulanit <sur...@am...> wrote: > I am using Ubuntu-12.10 and I installed the 2.6.34.14. When I build > oprofile with "--with-kernel" it doesn't even build "operf". I had to hack out some code in operf to get it to build (see initial message in this thread). But since then, I moved to 2.6.35. Sorry for the confusion. But I get the same error with this kernel as well. -- |
From: Kevin V. W. <va...@sa...> - 2013-04-03 17:02:09
|
On Wed, Apr 3, 2013 at 10:00 AM, Suthikulpanit, Suravee <Sur...@am...> wrote: > Kevin, > > Are you able to run profile as root? I started up the daemon and ran opreport so it seems to work: [root@n632001 ~]# /opt/oprofile/bin/opreport Using /var/lib/oprofile/samples/ for samples directory. CPU: CPU with timer interrupt, speed 3000.06 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| ------------------ 2827714 99.9894 vmlinux 221 0.0078 oprofiled 25 8.8e-04 libc-2.5.so 20 7.1e-04 opreport 18 6.4e-04 libstdc++.so.6.0.8 4 1.4e-04 e1000e 3 1.1e-04 bash 3 1.1e-04 libcrypto.so.0.9.8e 2 7.1e-05 igb 2 7.1e-05 ld-2.5.so 1 3.5e-05 libusb-0.1.so.4.4.4 1 3.5e-05 ntpd -- Kevin -- |
From: Kevin V. W. <va...@sa...> - 2013-04-03 17:08:26
|
On Wed, Apr 3, 2013 at 1:02 PM, Kevin Van Workum <va...@sa...> wrote: > On Wed, Apr 3, 2013 at 10:00 AM, Suthikulpanit, Suravee > <Sur...@am...> wrote: >> Kevin, >> >> Are you able to run profile as root? > > I started up the daemon and ran opreport so it seems to work: > > [root@n632001 ~]# /opt/oprofile/bin/opreport > Using /var/lib/oprofile/samples/ for samples directory. > CPU: CPU with timer interrupt, speed 3000.06 MHz (estimated) > Profiling through timer interrupt > TIMER:0| > samples| %| > ------------------ > 2827714 99.9894 vmlinux > 221 0.0078 oprofiled > 25 8.8e-04 libc-2.5.so > 20 7.1e-04 opreport > 18 6.4e-04 libstdc++.so.6.0.8 > 4 1.4e-04 e1000e > 3 1.1e-04 bash > 3 1.1e-04 libcrypto.so.0.9.8e > 2 7.1e-05 igb > 2 7.1e-05 ld-2.5.so > 1 3.5e-05 libusb-0.1.so.4.4.4 > 1 3.5e-05 ntpd > > -- > Kevin I also tried the op-check-perfevents program: # /opt/oprofile/bin/op-check-perfevents; echo $? 2 Strace reports: strace /opt/oprofile/bin/op-check-perfevents 2>&1 | tail -5 mprotect(0x30eec1b000, 4096, PROT_READ) = 0 munmap(0x7fa783438000, 88602) = 0 getpid() = 24529 mq_unlink("") = -1 ENOENT (No such file or directory) exit_group(2) = ? -- |
From: Kevin V. W. <va...@sa...> - 2013-04-03 17:19:29
|
On Wed, Apr 3, 2013 at 1:08 PM, Kevin Van Workum <va...@sa...> wrote: > On Wed, Apr 3, 2013 at 1:02 PM, Kevin Van Workum <va...@sa...> wrote: >> On Wed, Apr 3, 2013 at 10:00 AM, Suthikulpanit, Suravee >> <Sur...@am...> wrote: >>> Kevin, >>> >>> Are you able to run profile as root? >> >> I started up the daemon and ran opreport so it seems to work: >> >> [root@n632001 ~]# /opt/oprofile/bin/opreport >> Using /var/lib/oprofile/samples/ for samples directory. >> CPU: CPU with timer interrupt, speed 3000.06 MHz (estimated) >> Profiling through timer interrupt >> TIMER:0| >> samples| %| >> ------------------ >> 2827714 99.9894 vmlinux >> 221 0.0078 oprofiled >> 25 8.8e-04 libc-2.5.so >> 20 7.1e-04 opreport >> 18 6.4e-04 libstdc++.so.6.0.8 >> 4 1.4e-04 e1000e >> 3 1.1e-04 bash >> 3 1.1e-04 libcrypto.so.0.9.8e >> 2 7.1e-05 igb >> 2 7.1e-05 ld-2.5.so >> 1 3.5e-05 libusb-0.1.so.4.4.4 >> 1 3.5e-05 ntpd >> >> -- >> Kevin > > > I also tried the op-check-perfevents program: > # /opt/oprofile/bin/op-check-perfevents; echo $? > 2 > > Strace reports: > strace /opt/oprofile/bin/op-check-perfevents 2>&1 | tail -5 > mprotect(0x30eec1b000, 4096, PROT_READ) = 0 > munmap(0x7fa783438000, 88602) = 0 > getpid() = 24529 > mq_unlink("") = -1 ENOENT (No such file or directory) > exit_group(2) = ? At this point, I'm ready to tell my user it's not possible to run operf right now. Since only legacy mode works, I maybe able to convince the security Nazis to allow this. If not, I have to convince the QA Nazis to allow me to upgrade the OS and/or kernel. Either way though it won't be too useful for the end-user since they need to profile under the current production environment. If you guys want to keep debugging this, I'm willing to continue with your help. If not, fine by me. Many thanks to Suravee and Maynard for their help so far. -- Kevin -- |
From: Maynard J. <may...@us...> - 2013-04-03 23:13:44
|
On 04/03/2013 12:19 PM, Kevin Van Workum wrote: > On Wed, Apr 3, 2013 at 1:08 PM, Kevin Van Workum <va...@sa...> wrote: >> On Wed, Apr 3, 2013 at 1:02 PM, Kevin Van Workum <va...@sa...> wrote: >>> On Wed, Apr 3, 2013 at 10:00 AM, Suthikulpanit, Suravee >>> <Sur...@am...> wrote: >>>> Kevin, >>>> >>>> Are you able to run profile as root? >>> >>> I started up the daemon and ran opreport so it seems to work: >>> >>> [root@n632001 ~]# /opt/oprofile/bin/opreport >>> Using /var/lib/oprofile/samples/ for samples directory. >>> CPU: CPU with timer interrupt, speed 3000.06 MHz (estimated) >>> Profiling through timer interrupt >>> TIMER:0| >>> samples| %| >>> ------------------ >>> 2827714 99.9894 vmlinux >>> 221 0.0078 oprofiled >>> 25 8.8e-04 libc-2.5.so >>> 20 7.1e-04 opreport >>> 18 6.4e-04 libstdc++.so.6.0.8 >>> 4 1.4e-04 e1000e >>> 3 1.1e-04 bash >>> 3 1.1e-04 libcrypto.so.0.9.8e >>> 2 7.1e-05 igb >>> 2 7.1e-05 ld-2.5.so >>> 1 3.5e-05 libusb-0.1.so.4.4.4 >>> 1 3.5e-05 ntpd >>> >>> -- >>> Kevin >> >> >> I also tried the op-check-perfevents program: >> # /opt/oprofile/bin/op-check-perfevents; echo $? >> 2 >> >> Strace reports: >> strace /opt/oprofile/bin/op-check-perfevents 2>&1 | tail -5 >> mprotect(0x30eec1b000, 4096, PROT_READ) = 0 >> munmap(0x7fa783438000, 88602) = 0 >> getpid() = 24529 >> mq_unlink("") = -1 ENOENT (No such file or directory) >> exit_group(2) = ? > > At this point, I'm ready to tell my user it's not possible to run > operf right now. Since only legacy mode works, I maybe able to > convince the security Nazis to allow this. If not, I have to convince > the QA Nazis to allow me to upgrade the OS and/or kernel. Either way > though it won't be too useful for the end-user since they need to > profile under the current production environment. If you guys want to > keep debugging this, I'm willing to continue with your help. If not, > fine by me. Many thanks to Suravee and Maynard for their help so far. Kevin, According to the strace output, the ENOENT is coming from a "mq_unlink" call! I went back and re-read your initial post and saw your statement "I had to make a symlink to asm->asm_generic in the kernel's include dir". This would result in incorrect syscall numbers being used. Not your fault. I'm afraid the whole "--with-kernel" procedure was only half-baked and never properly tested. I'll post a patch to the list soon (and will cc you) that fixes the problem. Please start from scratch with a fresh git pull, apply my patch and follow the new instructions in the help text for the "--with-kernel" option. Then let me know how it went for you, good or bad. Thanks, and sorry for the headaches! -Maynard > > -- > Kevin > |
From: Maynard J. <may...@us...> - 2013-04-05 15:04:54
|
On 04/03/2013 06:13 PM, Maynard Johnson wrote: > On 04/03/2013 12:19 PM, Kevin Van Workum wrote: >> On Wed, Apr 3, 2013 at 1:08 PM, Kevin Van Workum <va...@sa...> wrote: >>> On Wed, Apr 3, 2013 at 1:02 PM, Kevin Van Workum <va...@sa...> wrote: >>>> On Wed, Apr 3, 2013 at 10:00 AM, Suthikulpanit, Suravee >>>> <Sur...@am...> wrote: >>>>> Kevin, >>>>> >>>>> Are you able to run profile as root? >>>> >>>> I started up the daemon and ran opreport so it seems to work: >>>> >>>> [root@n632001 ~]# /opt/oprofile/bin/opreport >>>> Using /var/lib/oprofile/samples/ for samples directory. >>>> CPU: CPU with timer interrupt, speed 3000.06 MHz (estimated) >>>> Profiling through timer interrupt >>>> TIMER:0| >>>> samples| %| >>>> ------------------ >>>> 2827714 99.9894 vmlinux >>>> 221 0.0078 oprofiled >>>> 25 8.8e-04 libc-2.5.so >>>> 20 7.1e-04 opreport >>>> 18 6.4e-04 libstdc++.so.6.0.8 >>>> 4 1.4e-04 e1000e >>>> 3 1.1e-04 bash >>>> 3 1.1e-04 libcrypto.so.0.9.8e >>>> 2 7.1e-05 igb >>>> 2 7.1e-05 ld-2.5.so >>>> 1 3.5e-05 libusb-0.1.so.4.4.4 >>>> 1 3.5e-05 ntpd >>>> >>>> -- >>>> Kevin >>> >>> >>> I also tried the op-check-perfevents program: >>> # /opt/oprofile/bin/op-check-perfevents; echo $? >>> 2 >>> >>> Strace reports: >>> strace /opt/oprofile/bin/op-check-perfevents 2>&1 | tail -5 >>> mprotect(0x30eec1b000, 4096, PROT_READ) = 0 >>> munmap(0x7fa783438000, 88602) = 0 >>> getpid() = 24529 >>> mq_unlink("") = -1 ENOENT (No such file or directory) >>> exit_group(2) = ? >> >> At this point, I'm ready to tell my user it's not possible to run >> operf right now. Since only legacy mode works, I maybe able to >> convince the security Nazis to allow this. If not, I have to convince >> the QA Nazis to allow me to upgrade the OS and/or kernel. Either way >> though it won't be too useful for the end-user since they need to >> profile under the current production environment. If you guys want to >> keep debugging this, I'm willing to continue with your help. If not, >> fine by me. Many thanks to Suravee and Maynard for their help so far. > > Kevin, > According to the strace output, the ENOENT is coming from a "mq_unlink" call! I went back and re-read your initial post and saw your statement "I had to make a symlink to asm->asm_generic in the kernel's include dir". This would result in incorrect syscall numbers being used. Not your fault. I'm afraid the whole "--with-kernel" procedure was only half-baked and never properly tested. I'll post a patch to the list soon (and will cc you) that fixes the problem. Please start from scratch with a fresh git pull, apply my patch and follow the new instructions in the help text for the "--with-kernel" option. Then let me know how it went for you, good or bad. Kevin, Would you be able to find time to test the patch I posted to the list on Wednesday? Thanks. -Maynard > > Thanks, and sorry for the headaches! > > -Maynard >> >> -- >> Kevin >> > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |