Bug 215729 - oprofile won't work because "cpu_type 'unset' is not valid"
oprofile won't work because "cpu_type 'unset' is not valid"
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: oprofile (Show other bugs)
5
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: William Cohen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-15 09:15 EST by Bruno Roggeri
Modified: 2008-05-06 12:50 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:50:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Roggeri 2006-11-15 09:15:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.13) Gecko/20060501 Epiphany/2.14

Description of problem:
On my system, any operation from opcontrol fails with "cpu_type 'unset' is not valid"

For example, running "opcontrol --init" as root just gives :
cpu_type 'unset' is not valid

I can check that the oprofile module is loaded :
$ /sbin/lsmod |grep oprofile
oprofile              144689  1

Those 2 lines appear in dmesg :
oprofile: using NMI interrupt.
SELinux: initialized (dev oprofilefs, type oprofilefs), uses genfs_contexts

The /dev/oprofile directory is populated :
$ ls -l /dev/oprofile/
total 0
drwxr-xr-x 1 root root 0 nov 15 14:52 0
drwxr-xr-x 1 root root 0 nov 15 14:52 1
-rw-r--r-- 1 root root 0 nov 15 14:52 backtrace_depth
-rw-r--r-- 1 root root 0 nov 15 14:52 buffer
-rw-r--r-- 1 root root 0 nov 15 14:52 buffer_size
-rw-r--r-- 1 root root 0 nov 15 14:52 buffer_watershed
-rw-r--r-- 1 root root 0 nov 15 14:52 cpu_buffer_size
-rw-r--r-- 1 root root 0 nov 15 14:52 cpu_type
-rw-rw-rw- 1 root root 0 nov 15 14:52 dump
-rw-r--r-- 1 root root 0 nov 15 14:52 enable
-rw-r--r-- 1 root root 0 nov 15 14:52 pointer_size
drwxr-xr-x 1 root root 0 nov 15 14:52 stats

But at least the content of /dev/oprofile/cpu_type is problematic : it's empty.

You can find the content of /proc/cpuinfo below.

Version-Release number of selected component (if applicable):
oprofile-0.9.1-8.1.1, kernel-2.6.18-1.2239.fc5

How reproducible:
Always


Steps to Reproduce:
1. opcontrol --init
2.
3.

Actual Results:
cpu_type 'unset' is not valid

The /dev/oprofile directory is populated but /dev/oprofile/cpu_type is an empty file

Expected Results:
/dev/oprofile/cpu_type should contain "i386/core2" or something like that

Additional info:
This is an double - double core from intel (so there's a total of 4 cores)

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
stepping        : 6
cpu MHz         : 1998.000
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 5322.22
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
stepping        : 6
cpu MHz         : 1998.000
cache size      : 4096 KB
physical id     : 3
siblings        : 2
core id         : 0
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 5319.28
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
stepping        : 6
cpu MHz         : 1998.000
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 5319.33
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5150  @ 2.66GHz
stepping        : 6
cpu MHz         : 1998.000
cache size      : 4096 KB
physical id     : 3
siblings        : 2
core id         : 1
cpu cores       : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 5319.26
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
Comment 1 William Cohen 2006-11-20 14:46:57 EST
OProfile 0.9.1-8.1.1 doesn't have support for core2. Core 2 support was added to
OProfile 0.9.2. The oprofile 0.9.1 rpms don't have support for Core 2. Take a
look in /usr/share/oprofile/i386. Is there a core_2 directory there?

The kernel should either return cpu_type that is something other than empty,
either the appropriate hardware name or "timer". Looking at the source code for
2.6.18-1.2247.fc5 does define i386/core_2. Is "more /dev/oprofile/cpu_type"
returning empty string? It appears that the oprofile driver is identifying the
hardware (the "0" and "1" performance counter directories), so it is surprising
the the cpu_type is not correct.
Comment 2 Bruno Roggeri 2006-11-21 05:51:38 EST
(In reply to comment #1)
> OProfile 0.9.1-8.1.1 doesn't have support for core2. Core 2 support was added to
> OProfile 0.9.2. The oprofile 0.9.1 rpms don't have support for Core 2. Take a
> look in /usr/share/oprofile/i386. Is there a core_2 directory there?

No, you're right there isn't.

> The kernel should either return cpu_type that is something other than empty,
> either the appropriate hardware name or "timer". Looking at the source code for
> 2.6.18-1.2247.fc5 does define i386/core_2. Is "more /dev/oprofile/cpu_type"
> returning empty string? 

Oops, you're right again, the line was erased by the shell prompt when I used
cat, but using "more" reveals it's content.

Thanks a lot for your help ! I see now that I just need to upgrade to
oprofile-0.9.2 .

Are there plans to update FC5's oprofile rpm to 0.9.2, or is my best bet is to
[roll my own / switch to FC6] ?



Comment 3 William Cohen 2006-11-21 09:26:16 EST
Currently there are no plans to upgrade the FC5 oprofile rpm to 0.9.2. However
it should be relatively easy to build the 0.9.2 srpm from fc6 on fc5. I am not
sure about attempting to install the fc5 binary rpm due to shared library
dependencies.

-Will
Comment 4 Bruno Roggeri 2006-11-21 10:19:57 EST
(In reply to comment #3)
> Currently there are no plans to upgrade the FC5 oprofile rpm to 0.9.2. However
> it should be relatively easy to build the 0.9.2 srpm from fc6 on fc5. 

OK. I managed to build a fc5 rpm from the fc6 srpm by first doing 
"rpmbuild --rebuild oprofile-0.9.2-3.fc6.src.rpm", then installing all the
packages it complained about but binutils-devel (which doesn't exists in fc5
because it is included in binutils), and then forcing the build with "rpmbuild
--rebuild oprofile-0.9.2-3.fc6.src.rpm --nodeps".


> I am not
> sure about attempting to install the fc5 binary rpm due to shared library
> dependencies.

I guess you mean "to install the fc6 binary". I didn't try though, the above
method is working for me.

Thank you again, goodbye

Bruno
Comment 5 William Cohen 2006-12-20 11:56:53 EST
Added the Intel Core and Core2 support patches to the rpm. oprofile-0.9.1-9 for
FC-5 should have the support for Intel Core and Core 2 processors.
Comment 6 Bug Zapper 2008-04-04 00:42:18 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 7 Bug Zapper 2008-05-06 12:50:02 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.