Bug 1794049

Here is the justification offered by the customer:

"Since lshw has decided to pull in things like all the cpu flags, which are also present in /proc/cpuinfo, then they should also pull in stepping, family, etc. Why should we need to pull from multiple sources when one will do?"

Hi, Matthew Whitehead

About the NUMA information, people can get more details via numactl tool, and the numa information is not present in '/proc/cpuinfo'. So I don't think that it's good choice to add the numa information to the lshw. But, there may be reasonable to output the cpu family, stepping and mode via lshw.

Here is a patch: https://github.com/lyonel/lshw/pull/50. Let's wait for the reply from maintainer and to see how he thinks about this patch. 

In addition, we could also discuss in upstream. Thanks.

Merged in upstream: f914f225975b ("report CPU family/model/stepping"). But there are different styles, for example:

[root@localhost lshw]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 142
model name	: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
stepping	: 9
microcode	: 0x84
cpu MHz		: 800.012
cache size	: 4096 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
......

[root@localhost lshw]# ./src/lshw -c cpu

  *-cpu                     
       description: CPU
       product: Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz
       vendor: Intel Corp.
       physical id: a
       bus info: cpu@0
       version: 6.142.9
                ^^^^^^^ ---the version indicates that cpu family, model and stepping.
......

Verified with lshw-B.02.19.2-2.el8.  The CPU family, model, and stepping values show up in the "version" field below.  In this case, they are family 6, model 158, stepping 11:

[root@dell-pet140-01 ~]# rpm -q lshw
lshw-B.02.19.2-2.el8.x86_64

[root@dell-pet140-01 ~]# lshw -class cpu
  *-cpu                     
       description: CPU
       product: Intel(R) Celeron(R) G4900 CPU @ 3.10GHz
       vendor: Intel Corp.
       physical id: 400
       bus info: cpu@0
       version: 6.158.11                                       <------ family.model.stepping
       slot: CPU1
       size: 3099MHz
       capacity: 4GHz
       width: 64 bits
       clock: 100MHz
       capabilities: lm fpu fpu_exception wp 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 pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms invpcid mpx rdseed smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm arat pln pts hwp hwp_act_window hwp_epp md_clear flush_l1d cpufreq
       configuration: cores=2 enabledcores=2 microcode=214 threads=2

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (lshw bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4533