Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.12.3 available

The official documentation can be found on https://wiki.ocsinventory-ng.org. Read it before asking your question.

Categories

Agent 2.4 for Unix - wrong number of CPUS

Hello,

I'm pretty new to OCS Inventory NG and I was suffering from the issue which is also discussed here:

http://ask.ocsinventory-ng.org/3705/wrong-number-operating-system-enterprise-linux-server-release

My installation is quite old, but I already have version 2.4 up and running and I'm currently planning the migration to the new version.

So right now I'm using OCS inventory server version 2.4 and ocsinventory-agent-2.4.0-1.el7.ocs.src.rpm (from the repo) which is reported as NG_unified_unix_agent_v2.3.1 in the web frontend.

I upgraded the ocsinventory-agent to version 2.4 on one of my RHEL 7.4  boxes and the number of CPUs is still wrong. With the old version I always had +1 CPU, but now the frontend shows me 128 rows, whereas only 1 row contains useful information.

It shows 

PROCESSOR(S)

1-10 Result(s) (Download)

128 Result(s) (Download)

at the top of the hardware page.

cat /proc/cpuinfo 

processor       : 0

vendor_id       : GenuineIntel

cpu family      : 6

model           : 63

model name      : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz

stepping        : 0

microcode       : 0x37

cpu MHz         : 2593.993

cache size      : 30720 KB

physical id     : 0

siblings        : 1

core id         : 0

cpu cores       : 1

apicid          : 0

initial apicid  : 0

fpu             : yes

fpu_exception   : yes

cpuid level     : 13

wp              : yes

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov                                                                                                                                                              pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant                                                                                                                                                             _tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf ea                                                                                                                                                             gerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_d                                                                                                                                                             eadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm epb invpcid_singl                                                                                                                                                             e fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid xsaveopt dtherm ida arat pln p                                                                                                                                                             ts

bogomips        : 5187.98

clflush size    : 64

cache_alignment : 64

address sizes   : 42 bits physical, 48 bits virtual

power management:

Could you please advise?

Regards,

Lars

in OCS Inventory NG agent for Unix by (670 points)
Share on
share on gp share on fb share on tw share on li

8 Answers

0 votes
Hi,

Is your RHEL 7.4 box virtual or physical? Could you please post result of "dmidecode -t processor" command? And which version did you used before upgrading?

Regards

Frank
by (90.2k points)
0 votes

Hi Frank,

it's a VM . Output from dmidecode -t processor is quite long ... So I placed only an excerpt at the end of my answer. Prior to upgrading the agent it was ocsinventory-agent-2.1.1-1.el7.remi.x86_64 using server version 2.2.

Regards,

Lars
 

# dmidecode 3.0

Getting SMBIOS data from sysfs.

SMBIOS 2.4 present.

Handle 0x0004, DMI type 4, 35 bytes

Processor Information

Socket Designation: CPU socket #0

Type: Central Processor

Family: Unknown

Manufacturer: GenuineIntel

ID: F0 06 03 00 FF FB AB 0F

Version: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz

Voltage: 3.3 V

External Clock: Unknown

Max Speed: 30000 MHz

Current Speed: 2600 MHz

Status: Populated, Enabled

Upgrade: ZIF Socket

L1 Cache Handle: 0x0094

L2 Cache Handle: 0x0095

L3 Cache Handle: Not Provided

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

[...] up to

Handle 0x0083, DMI type 4, 35 bytes

Processor Information

Socket Designation: CPU socket #127

Type: Central Processor

Family: Unknown

Manufacturer: GenuineIntel

ID: F0 06 00 00 FF FB AB 0F

Version: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz

Voltage: 3.3 V

External Clock: Unknown

Max Speed: 30000 MHz

Current Speed: 2600 MHz

Status: Populated, Disabled By BIOS

Upgrade: ZIF Socket

L1 Cache Handle: 0x0192

L2 Cache Handle: 0x0193

L3 Cache Handle: Not Provided

Serial Number: Not Specified

Asset Tag: Not Specified

Part Number: Not Specified

by (670 points)
0 votes

Hi Frank, after pointing me to dmidecode one of colleagues and I checked a recent Debian system with dmidecode version 3.1 and one of our RHEL 7.4 boxes with dmidecode version 3.0 and there is a difference ...

  Kernel versions are of course different too.

Debian / dmidecode version 3.1

dmidecode -t processor | grep 'Status'

        Status: Populated, Enabled

        Status: Populated, Enabled

        Status: Populated, Enabled

        Status: Populated, Enabled

        Status: Unpopulated

        Status: Unpopulated

        Status: Unpopulated

        Status: Unpopulated

        Status: Unpopulated

vs.

RHEL7 / dmidecode version 3.0

dmidecode -t processor | grep 'Status'

        Status: Populated, Enabled

        Status: Populated, Enabled

        Status: Populated, Disabled By BIOS

        Status: Populated, Disabled By BIOS

        Status: Populated, Disabled By BIOS

        Status: Populated, Disabled By BIOS

        Status: Populated, Disabled By BIOS

Looking at 

/usr/share/perl5/vendor_perl/Ocsinventory/Agent/Backend/OS/Linux/Archs/i386/CPU.pm there is

 foreach my $line (@dmidecode) {

        chomp $line;

        $socket++ if($line =~ /^Handle/);   # handle opens a new processor in dmidecode output

        next if $socket < 0;    # if in preface still

        if($line =~ /^\s*$/ ) { # end of processor/socket found

            if ( $status ne "Unpopulated") {

Regards,

Lars

by (670 points)
0 votes

Hello Frank,

do you plan to correct the behavior and release a new version of the  perl-Ocsinventory-Agent RPM for RHEL7, or should we try to fix it on our own?

Regards,

Lars

by (670 points)
+2 votes
Hi,

Open an issue at https://github.com/OCSInventory-NG/UnixAgent/issues/new to follow corrections and evolutions. We'll correct this problem. Post all is needed to resolve this problem on the issue.
Regards

Frank
by (90.2k points)
+1 vote
Hello Frank,

any news here? As requested I opened an issue for this problem on April 4th.
Regards,

Lars
by (670 points)
+1 vote
Hi,

Now currently working on it.

Regards

Frank
by (90.2k points)
+1 vote
Hello,

We are facing the same problem. Currently, dmidecode-3.0-5 is shipped with RHEL 7.5 and I didn't find any information for a newer version of dmidecode to be shipped with the next update(s) of RHEL 7.

As we are deploying ocsinventory-agent-2.4.0-1 v with puppet, we have to modify the /usr/share/perl5/vendor_perl/Ocsinventory/Agent/Backend/OS/Linux/Archs/i386/CPU.pm file on all RHEL 7 machines (thanks to gcinfra for the tip). But it's barely putting a band-aid on a wooden leg.

Can you tell us when new versions of ocsinventory-agent packages will be released in the rpm repository? Thank you.

Regards,

BorisPB
by (170 points)
 
Powered by Question2Answer
...