Testers for inxi/pinxi redone -C CPU logic... huge internal changes

h2-1 · 11-27-2021, 10:05 PM

bw42, a PowerPC, you are making my day!! That's exactly where I would expect bugs to pop up, since I have no way to test that, very glad you have one of those. I will see if I can resolve that issue.

The Kaby Lake/Comet Lake is a real pain, that's actually why inxi says 'note: check', it knows that it can't actually tell them apart in some steppings. But I'll double check that to make sure, but it basically comes down to Intel using product names as marketing devices, not engineering terms, since obviously if it was an actual different cpu it would have a different stepping, at least that's how I understand it. This issue also happened with Zen > Zen+, by the way, and has happened a few other times. But I'll double check that to make sure it can't be improved.

cpu-world.com is doing a really good job, they are my go-to now for all confirmations of data, what they are doing is a real service to the entire tech community. Unlike other sources that often contradicted eachother, they really seem to be getting the data right, though nobody is perfect since it's quite empirical at times.

The Aarch server is another perfect example of a total fail, anytime you see: ERR-103 in the new CPU logic it is actually a code that tells me that some logic totally failed to execute at all that should have been able to execute if the stuff had worked.

I'll work up a debugger for that one, I had it lying around but can't find it. Just a one liner.

bw42 · 11-27-2021, 10:19 PM

I uploaded debug logs for the Aarch64 system, and for my RISC-V HiFive Unmatched in case you add support for RISC-V at some point.
The RISC-V was almost a complete failure at reading anything, which I expected.

Code:

Machine:
  Smbios: No SMBIOS data for dmidecode to process

CPU:
  Info: ERR-103
    model: N/A
    bits: 64
    type: UP
    arch: N/A
    family: N/A
    model-id: N/A
    stepping: N/A
    microcode: N/A
    cache:
      L1: 256 KiB
        desc: d-4x32 KiB; i-4x32 KiB
      L2: 2 MiB
        desc: 1x2 MiB
    flags: N/A
    bogomips: 0
  Speed: N/A
    min/max: N/A
    core: No per core speed data found.
  Vulnerabilities: No CPU vulnerability/bugs data available.

pghvlaans · 11-27-2021, 10:21 PM

In case it helps, lspci also reports Comet Lake:

Code:

 # lspci -mm -nn
00:00.0 "Host bridge [0600]" "Intel Corporation [8086]" "Comet Lake-U v1 4c Host Bridge/DRAM Controller [9b61]" -r0c "Unknown vendor [3100]" "Device [0002]"
00:02.0 "VGA compatible controller [0300]" "Intel Corporation [8086]" "CometLake-U GT2 [UHD Graphics] [9b41]" -r02 "Unknown vendor [3100]" "Device [0002]"
00:08.0 "System peripheral [0880]" "Intel Corporation [8086]" "Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [1911]" "Unknown vendor [3100]" "Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model [0004]"
00:12.0 "Signal processing controller [1180]" "Intel Corporation [8086]" "Comet Lake Thermal Subsytem [02f9]" "Unknown vendor [3100]" "Device [0002]"
00:14.0 "USB controller [0c03]" "Intel Corporation [8086]" "Comet Lake PCH-LP USB 3.1 xHCI Host Controller [02ed]" -p30 "Unknown vendor [3100]" "Device [0002]"
00:14.2 "RAM memory [0500]" "Intel Corporation [8086]" "Comet Lake PCH-LP Shared SRAM [02ef]" "Unknown vendor [3100]" "Device [0002]"
00:15.0 "Serial bus controller [0c80]" "Intel Corporation [8086]" "Serial IO I2C Host Controller [02e8]" "Unknown vendor [3100]" "Device [0002]"
00:16.0 "Communication controller [0780]" "Intel Corporation [8086]" "Comet Lake Management Engine
Interface [02e0]" "Unknown vendor [3100]" "Device [0002]"
00:17.0 "RAID bus controller [0104]" "Intel Corporation [8086]" "82801 Mobile SATA Controller [RAID mode] [282a]" "Unknown vendor [3100]" "82801 Mobile SATA Controller [RAID mode] [0004]"
00:19.0 "Serial bus controller [0c80]" "Intel Corporation [8086]" "Comet Lake Serial IO I2C Host Controller [02c5]" "Unknown vendor [3100]" "Device [0002]"
00:1d.0 "PCI bridge [0604]" "Intel Corporation [8086]" "Comet Lake PCI Express Root Port #9 [02b0]" -rf0 "" ""
00:1d.1 "PCI bridge [0604]" "Intel Corporation [8086]" "Comet Lake PCI Express Root Port #10 [02b1]" -rf0 "" ""
00:1d.3 "PCI bridge [0604]" "Intel Corporation [8086]" "Comet Lake PCI Express Root Port #12 [02b3]" -rf0 "" ""
00:1d.4 "PCI bridge [0604]" "Intel Corporation [8086]" "Comet Lake PCI Express Root Port #13 [02b4]" -rf0 "" ""
00:1f.0 "ISA bridge [0601]" "Intel Corporation [8086]" "Comet Lake PCH-LP LPC Premium Controller/eSPI Controller [0284]" "Unknown vendor [3100]" "Device [0002]"
00:1f.3 "Audio device [0403]" "Intel Corporation [8086]" "Comet Lake PCH-LP cAVS [02c8]" "Unknown vendor [3100]" "Device [0001]"
00:1f.4 "SMBus [0c05]" "Intel Corporation [8086]" "Comet Lake PCH-LP SMBus Host Controller [02a3]"
"Unknown vendor [3100]" "Device [0002]"
00:1f.5 "Serial bus controller [0c80]" "Intel Corporation [8086]" "Comet Lake SPI (flash) Controller [02a4]" "Unknown vendor [3100]" "Device [0002]"
01:00.0 "Ethernet controller [0200]" "Realtek Semiconductor Co., Ltd. [10ec]" "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [8168]" -r15 "Unknown vendor [3100]" "RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [0002]"
02:00.0 "Unassigned class [ff00]" "Realtek Semiconductor Co., Ltd. [10ec]" "RTS524A PCI Express Card Reader [524a]" -r01 "Realtek Semiconductor Co., Ltd. [10ec]" "RTS524A PCI Express Card Reader [524a]"
03:00.0 "Network controller [0280]" "Intel Corporation [8086]" "Wi-Fi 6 AX200 [2723]" -r1a "Intel Corporation [8086]" "Wi-Fi 6 AX200NGW [0084]"
04:00.0 "Non-Volatile memory controller [0108]" "Samsung Electronics Co Ltd [144d]" "NVMe SSD Controller 980 [a809]" -p02 "Samsung Electronics Co Ltd [144d]" "Device [a801]"

h2-1 · 11-27-2021, 10:40 PM

pghvlaans, yeah, the drag is, those are Intel architectures in lspci strings, not actual data, that's always been annoying because you see the value you want in the string, but it's not actual data. In Intel systems, you'll also see devices from different architectures listed, like one in the GPU, another in the CPU, but not the same ones.

I'm going to take a look however, but if it's an ambiguous stepping inxi can't 'know' which it is, unfortunately, I beat my head against that one off and on during recent architecture updates. That's a matching table, sort of, empirical, you can't actually get the architecture name from the system, same as for vendors, those are also created by internal manually constructed matching table, same for ram vendors by the way. On rare occasions you can get ram vendors internally, but usually not, it has to be matched to the product string.

So far great stuff, far better than hoped for.

Debugger data sets from AArch and PPC should show show me causes for sure, thanks a lot for those. The hex character may be slightly difficult to deal with, I had to handle an issue like that for weather, for russian characters, and htat was very tricky, I didn't do it globally, just in weather.

risc-v worked spectacularly well by the way, no errors!! Everything handled internally, that's actually very impressive, it suggests support can be added, though I've never seen a dataset before, so will be interesting to see what they look like.

h2-1 · 11-27-2021, 11:00 PM

pghvlaans, that may be a real bug with the stepping, I have to check that, carefully. It looks like stepping is converted to hex, but then is sent to the matching table, which is looking for integers, but I have to make triple sure about this before fixing that, but you may have found a really significant bug which will impact a lot of Intel architecture detections, since a lot of them depend on stepping, not model number. The ID if it was working should have returned: Comet/Whiskey Lake but returned the fallback case, Kaby Lake.

I'd honestly always been unclear if the stepping in cpuinfo was hex or decimal, but during research for this refactor, I finally came across something that was unambiguous about it. I'm going to run a quick test on this, and if you can confirm if it worked, I'll know that was the bug, which seems to be a bug in inxi, maybe one that's been there for a while. My problem has always been that all the Intel servers I have access to just happen to have steppings less than 10, so this issue never really was obvious, but I have to be very careful in this one. But it looks like a significant bug in pinxi/inxi for mainly Intel CPUs. Exactly what I was hoping to find.

bw42, I'll check your stuff and post if I see anything.

pghvlaans · 11-27-2021, 11:09 PM

Interesting. Just let me know, and I'll run the checks.

JayByrd · 11-27-2021, 11:18 PM

Looks good here. Nothing "exotic," but here's the output for one of my BOINC crunching rigs:

Code:

mikebig@BOINC5:~$ inxi -MCazy
Machine:
  Type: Desktop Mobo: MSI model: K9N6PGM2-V2 (MS-7309) v: 2.0
  serial: <superuser required> BIOS: American Megatrends v: 2.7
  date: 11/22/2010
CPU:
  Info: Dual Core model: AMD Athlon II X2 245 bits: 64 type: MCP arch: K10
  family: 10 (16) model-id: 6 stepping: 2 microcode: 10000C7 cache:
  L1: 256 KiB L2: 2 MiB
  flags: ht lm nx pae sse sse2 sse3 sse4a svm bogomips: 11652
  Speed: 2900 MHz min/max: 800/2900 MHz boost: disabled Core speeds (MHz):
  1: 2900 2: 2900
  Vulnerabilities: No CPU vulnerability/bugs data available.

mikebig@BOINC5:~$ ./pinxi -MCazy1
Machine:
  Type: Desktop
  Mobo: MSI
    model: K9N6PGM2-V2 (MS-7309)
    v: 2.0
    serial: <superuser required>
  BIOS: American Megatrends
    v: 2.7
    date: 11/22/2010

CPU:
  Info: Dual Core
    model: AMD Athlon II X2 245
    bits: 64
    type: MCP
    arch: K10
    family: 10 (16)
    model-id: 6
    stepping: 2
    microcode: 10000C7
    cache:
      L1: 256 KiB
        desc: d-2x64 KiB; i-2x64 KiB
      L2: 2 MiB
        desc: 2x1024 KiB
    flags: ht lm nx pae sse sse2 sse3 sse4a svm
    bogomips: 5826
  Speed (MHz):
    avg: 2900
    min/max: 800/2900
    boost: disabled
    cores:
      1: 2900
      2: 2900
  Vulnerabilities: No CPU vulnerability/bugs data available.

h2-1 · 11-27-2021, 11:32 PM

bw42, pghvlaans, somehow, you both managed to find manifestations of the same bug, LOL. This is far better than I hoped for, and in particular, this area I had not even really double checked at all, since it wasn't part of the core refactor. the PPC error was also directly caused by failing to test that the number to be converted from hex to decimal was an actual hex number.

So Perl and inxi did not do well trying to convert: 2.2 (pvr 004e 1202) (2)
into decimal from hex, lol. MIPS, PPC and to some lesser extent, ARM, also tend to put various strings into the stepping or revision fields, so this was going to hit more people than just this single case.

The logic internally was correctly turning the stepping integer into hex, but it had not been updated then in the cpu architecture function to then check to make sure it was dealing with a hex number and convert it back to decimal, and it was also only doing a simple is numeric test, that I think was from an older version of the logic where I was not converting the integer stepping value to hex the way I do with model id and family id.

So this was a really excellent start, very promising, several related bugs in an area I did very little double checks of the logic, and which I had not refactored, and none of my cpus had steppings > 9, nor were they ever giving a non integer value for stepping/revision/rev, so I never saw it.

pinxi 3.3.09-10 should have these two issues handled.

Code:

pinxi -U

to get fixed version.

This means the intel arch has been wrong in all cases where the stepping was > 9, which is a drag

Excellent so far, will keep digging into the data.

Many thanks for finding such failures so quickly.

Interestingly, a Manjaro person also found a stepping bug, but that was one where I'd forgotten to add a fix in to protect against the case of stepping 0 being treated as false, not a valid value. That is also fixed.

nobodino · 11-27-2021, 11:33 PM

@h2-1: interesting tool, and lots of information.

pghvlaans · 11-27-2021, 11:39 PM

The new version is looking good here:

Code:

 $ pinxi --version | grep ^pinxi
pinxi 3.3.09-10 (2021-11-26)
 $
 $ pinxi -MCazy
Machine:
  Type: Laptop System: Dynabook product: dynabook P1-C7MP-BL v: P1C7MPBL
  serial: <superuser required>
  Mobo: Dynabook model: DBIINV00 v: Type2 - Board Version
  serial: <superuser required> UEFI: Insyde v: 1.90 date: 08/28/2020
CPU:
  Info: Quad Core model: Intel Core i7-10510U bits: 64 type: MT MCP
  arch: Comet/Whiskey Lake note: check family: 6 model-id: 8E (142)
  stepping: C (12) microcode: EA cache: L1: 256 KiB
  desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB L3: 8 MiB
  desc: 1x8 MiB
  flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 4599
  Speed (MHz): avg: 852 high: 1220 min/max: 400/4900 cores: 1: 800 2: 799
  3: 800 4: 800 5: 1220 6: 800 7: 798 8: 800
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
  mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling
  Type: srbds mitigation: TSX disabled
  Type: tsx_async_abort status: Not affected

JayByrd · 11-27-2021, 11:40 PM

An even older (2004) AMD box:

Code:

mikebig@BOINC0:~$ inxi -MCazy
Machine:
  Type: Desktop Mobo: Shuttle model: MN31 serial: <superuser required>
  BIOS: Phoenix v: 6.00 PG date: 08/23/2004
CPU:
  Info: Single Core model: AMD Athlon XP 2500+ bits: 32 type: UP
  arch: K7 Palomino+ family: 6 model-id: A (10) stepping: 0 microcode: N/A
  cache: L1: 128 KiB L2: 512 KiB
  flags: pae sse bogomips: 3704
  Speed: 1837 MHz min/max: 1287/1837 MHz Core speed (MHz): 1: 1837
  Vulnerabilities: Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
  mitigation: Full generic retpoline, STIBP: disabled, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected

mikebig@BOINC0:~$ ./pinxi -MCazy1
Machine:
  Type: Desktop
  Mobo: Shuttle
    model: MN31
    serial: <superuser required>
  BIOS: Phoenix
    v: 6.00 PG
    date: 08/23/2004

CPU:
  Info: Single Core
    model: AMD Athlon XP 2500+
    bits: 32
    type: UP
    arch: K7 Palomino+
    family: 6
    model-id: A (10)
    stepping: 0
    microcode: N/A
    cache:
      L1: 128 KiB
        desc: d-1x64 KiB; i-1x64 KiB
      L2: 512 KiB
        desc: 1x512 KiB
    flags: pae sse
    bogomips: 3704
  Speed (MHz): 1837
    min/max: 1287/1837
    core:
      1: 1837
  Vulnerabilities:
    Type: itlb_multihit
      status: Not affected
    Type: l1tf
      status: Not affected
    Type: mds
      status: Not affected
    Type: meltdown
      status: Not affected
    Type: spec_store_bypass
      status: Vulnerable
    Type: spectre_v1
      mitigation: usercopy/swapgs barriers and __user pointer sanitization
    Type: spectre_v2
      mitigation: Full generic retpoline, STIBP: disabled, RSB filling
    Type: srbds
      status: Not affected
    Type: tsx_async_abort
      status: Not affected

h2-1 · 11-27-2021, 11:41 PM

JayByrd, another excellent one, I was almost kicking myself because I had just converted my old athlon x2 box to ryzen about a month or two before starting this refactor, and I was wanting to see what happened on that specific cpu.

Any old hardware is really great to test on, and also any super new stuff, I think I have a guy on monday who is going to shoot me data from his alder lake, that's the real test for this refactor, so far it should work exactly as intended unless there are bugs, keeping my fingers crossed on that one. But from what I am seeing so far, pretty much anything and everything is great to test on. Remember to update with pinxi -U to get the latest fixes each time. I'll try to remember to up the patch number each commit so you can tell you got the latest.

many thanks, these are all extremely useful.

nobodino, sometimes I worry it's getting too much information, if you saw it when it was version 0.1 compared to now, it's a huge difference, and sometimes I worry there is too much, but a lot of it is directly due to end user feature requests (or my own feature requests for my own needs), so it is is what it is I guess. I hope that the verbosity extra data levels help control that, and do always try to keep the non extra data levels to as short and concise as possible, like -b for instance. But it's a challenge balancing clarity and non ambiguity with terseness brevity. -a/--admin was actually my solution to that dilemma, that one is allowed to be as verbose and long as required for precision.

volkerdi · 11-27-2021, 11:49 PM

From my old dev box:

Code:

volkerdi@hive64:/tmp$ ./pinxi -MCazy
Machine:
  Type: Desktop System: Gigabyte product: GA-890GPA-UD3H v: N/A
  serial: <superuser required> Chassis: type: 3 serial: <superuser required>
  Mobo: Gigabyte model: GA-890GPA-UD3H serial: <superuser required>
  BIOS: Award v: FF date: 11/24/2010
CPU:
  Info: 6-Core model: AMD Phenom II X6 1100T bits: 64 type: MCP arch: K10
  family: 10 (16) model-id: A (10) stepping: 0 microcode: 10000BF cache:
  L1: 768 KiB desc: d-6x64 KiB; i-6x64 KiB L2: 3 MiB desc: 6x512 KiB L3: 6 MiB
  desc: 1x6 MiB
  flags: ht lm nx pae sse sse2 sse3 sse4a svm bogomips: 6628
  Speed (MHz): avg: 1019 high: 1892 min/max: 800/3300 boost: enabled cores:
  1: 803 2: 803 3: 1014 4: 1892 5: 804 6: 803
  Vulnerabilities: Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass status: Not affected
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
  mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected

h2-1 · 11-27-2021, 11:51 PM

pghvlaans, I am super glad you and bw42 had hardware that exposed such a 'core' bug, instantly, this is exactly what I was hoping for, and even better, in both places where that bug could trigger. I hate doing a new inxi with such a glaring bug in existence, and I'm trying to not think of all the previous releases that have had that bug, that's very annoying. But this is a big reason I had to do the full CPU refactor, there were a lot of subtle and not so subtle bugs like that, many of which could not be fixed without rewriting all the logic.

The current fix is not perfect, but I think will cover virtually all meaningful cases, it's to search the stepping value for 1 to 3 hexidecimal characters, and only 1 to 3, and if it contains anything else, don't use it for hex conversions, just either set it to 0 for math tests in the stepping logic, or leave it as a string and don't try to convert it for the other logic bw42 tripped the error on.

bw42 · 11-28-2021, 12:14 AM

No error received on Power9 system after the update.

Code:

Machine:
  Type: PowerPC Device
  System: C1P9S01 REV 1.01
    details: N/A

CPU:
  Info: 8-Core
    model: POWER9 altivec supported
    bits: 64
    type: MT MCP
    arch: ppc64le
    family: N/A
    model-id: N/A
    stepping: 2.2 (pvr 004e 1202)
    cache:
      L1: 512 KiB
        desc: d-8x32 KiB; i-8x32 KiB
      L2: 4 MiB
        desc: 8x512 KiB
      L3: 80 MiB
        desc: 8x10 MiB
    flags: N/A
    bogomips: 0
  Speed (MHz):
    avg: 2703
    high: 3800
    min/max: 2166/3800
    boost: enabled
    cores:
      1: 2166
      2: 2166
      3: 2166
      4: 2166
      5: 3800
      6: 3800
      7: 3400
      8: 3400
      9: 2166
      10: 2166
      11: 2233
      12: 2916
      13: 2183
      14: 2183
      15: 2183
      16: 2183
      17: 2333
      18: 2816
      19: 2816
      20: 2816
      21: 2650
      22: 2650
      23: 2650
      24: 2650
      25: 3800
      26: 3800
      27: 3800
      28: 3800
      29: 2166
      30: 2166
      31: 2166
      32: 2166
  Vulnerabilities:
    Type: itlb_multihit
      status: Not affected
    Type: l1tf
      mitigation: RFI Flush, L1D private per thread
    Type: mds
      status: Not affected
    Type: meltdown
      mitigation: RFI Flush, L1D private per thread
    Type: spec_store_bypass
      mitigation: Kernel entry/exit barrier (eieio)
    Type: spectre_v1
      mitigation: __user pointer sanitization, ori31 speculation barrier enabled
    Type: spectre_v2
      mitigation: Indirect branch cache disabled, Software link stack flush
    Type: srbds
      status: Not affected
    Type: tsx_async_abort
      status: Not affected