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

After about a month or more of research, I was finally able to start the big CPU refactor, the very early parts of it were in inxi 3.3.09, but that was released mainly to get other bugs and issue fixes released, and had some temporary placeholder fixes and tools for CPU logic. Those are all gone, and replaced with the actual solution.

Because this is a huge change internally, and also because I had to do some very convoluted stuff to try to maintain BSD support and legacy ancient Linux support (and when I say ancient, I mean ancient), this will need a lot of testing on different hardware, aka, your hardware, since I’ve already tested it on mine.

# if you already have pinx installed:
pinxi -U
# if you don't, just do:
cd /usr/local/bin && sudo wget -O pinxi smxi.org/pinxi && sudo chmod +x pinxi

First run inxi to compare, it doesn’t matter a lot which version, although 3.3.09 had a few fixes that earlier versions were missing, like L1/L3 caches showing without root/sudo. This is from a system that showed the wrong number of Cores, 2x as many as existed, and the wrong L2 cache, that’s inxi 3.3.08.

Post with -M so I can see what the hardware is. Like:

inxi -MCazy
Machine: ....
  Info: 2x 6-Core model: Intel Xeon E5-2620 0 bits: 64 type: MCP SMP
  arch: Sandy Bridge family: 6 model-id: 2D (45) stepping: 7 microcode: 71A
  cache: L2: 30 MiB
  flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 48053
  Speed: 2304 MHz min/max: 1200/2500 MHz Core speeds (MHz): 1: 2304 2: 2307
  3: 2000 4: 2000 5: 2353 6: 2321 7: 2389 8: 2319 9: 2287 10: 2349 11: 2437
  12: 2338 13: 2302 14: 2391 15: 2324 16: 2338 17: 2355 18: 2308 19: 2332
  20: 2302 21: 1811 22: 1790 23: 1710 24: 1702
# with the new logic:

pinxi -MCazy1
Machine: ....
  Info: 2x 6-Core
    model: Intel Xeon E5-2620 0
    bits: 64
    type: MCP SMP
    arch: Sandy Bridge
    family: 6
    model-id: 2D (45)
    stepping: 7
    microcode: 71A
      L1: 2x 384 KiB (768 KiB)
        desc: d-6x32 KiB; i-6x32 KiB
      L2: 2x 1.5 MiB (3 MiB)
        desc: 6x256 KiB
      L3: 2x 15 MiB (30 MiB)
        desc: 1x15 MiB
    flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
    bogomips: 4000
  Speed (MHz):
    avg: 1682
    high: 2000
    min/max: 1200/2500
      1: 2000
      2: 2000
      3: 2000
      4: 2000
      5: 2000
      6: 1997
      7: 1609
      8: 1204
      9: 1207
      10: 1242
      11: 1383
      12: 1552

# Another sample of the new logic:
# which will show something like this:
pinxi -MCazy1
  Info: 6-Core
    model: AMD Ryzen 5 2600
    bits: 64
    type: MT MCP
    arch: Zen+
    family: 17 (23)
    model-id: 8
    stepping: 2
    microcode: 8008204
      L1: 576 KiB
        desc: d-6x32 KiB; i-6x64 KiB
      L2: 3 MiB
        desc: 6x512 KiB
      L3: 16 MiB
        desc: 2x8 MiB
    flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
    bogomips: 6799
  Speed (MHz):
    avg: 2717
    high: 3895
    min/max: 1550/3400
    boost: enabled
      1: 3326
      2: 2746
      3: 1454
      4: 1468
      5: 3895
      6: 3891
      7: 2674
      8: 2783
      9: 1559
      10: 1556
      11: 3475
      12: 3783

I just got the last features on my todo list done, so this is finally ready for testing.

Note that because these are very large changes, and the old logic is very difficult to work on, I’ve basically preserved a significantly modified version of the old logic, minus a few features that are in the new logic, like cpu min/max speeds, which can be accessed like so:

pinxi -MCay1 --force cpuinfo

Note it’s not exactly the old logic, but it’s a lot of it, only a bit more organized and cleaned up.

There’s a few things to check to see if it’s right, use cpu-world.com data, they are quite good, do a google search like so:

search: [your cpu model, like: AMD Ryzen 5 2600] cpu-world.com

Verify that the L1, L2, and L3 caches are all correct, particularly in the per CPU totals.

Verify that the CPU type: data is correct. Note that Alder Lake is supported, that was one big reason for the full refactor, the old logic could not handle that complex cpu topology/architecture, or other ones that are coming soon. Note some changes, with -Ca, you see how many of each type of L cache there are in each cpu, as well as the total for all physical cpus.

Many corner cases were failing using the old logic, in fact, the more I looked, the more corner cases I found that were failing, the goal here, which I think is realized unless you find bugs in the logic, is that if the data is ‘wrong’, it’s because the system reported the wrong data, which is fine, as long as inxi itself isn’t the cause of the data being wrong.

There are also some debuggers that are useful to paste into a pastebin in some cases, like:

pinxi -MCazy --dbg 39 --dbg 8

will basically spit out a huge amount of data, and the entire data structures being used, as well as the results, those can be useful to track down errors in the results.

The more obscure CPUs and hardware, old operating systems, ARM SOC devices, whatever, the better, this is one where I can only crudely test for failures, but there are debuggers built in that if you run pinxi --debug 22 to upload a debugger data set, contain files I can use, at least in theory, to debug the issue without even seeing the hardware, though that has not been fully tested yet, but it should in theory work.

Thanks for all hardware/operating systems.

The main thing for BSDs is just to compare inxi and pinxi output, and make sure it didn’t get worse for -Cay in pinxi, and ideally, maybe a touch better, but I think due to how little data those systems have to offer, there’s not a huge set of things that can go wrong with the output beyond the failures causes by not having enough data in the first place.

Tested on Debian 3,1, sarge, 4.0, etch, in VM, tested on 5.0 on 1998 hardware, tested on Openbsd 6.9 and 7.0. And newer hardware/servers/desktops/laptops.

Of particular interest are a certain generation of Intel core quadro that were made out of 2 core duos stuck together, along with several other Core Duos, and any ARM SOC that uses two different CPU blocks, with different speeds per block.


OK … updating just for you … one sec … :wink:

EDIT for you @h2-1 , sorry no core2duo :

$ inxi -MCazy | curl -F 'file=@-' https://0x0.st        
$ pinxi -MCazy | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy1 | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy --dbg 39 --dbg 8 | curl -F 'file=@-' https://0x0.st

Well that didn’t take long, lol, you found a bug in the stepping, I thought I hadn’t changed that stuff, probably messed up somewhere, thanks. I think I broke the stepping: 0 handler, lol, sigh.

The failure to show stepping should be corrected, thanks for having a cpu with stepping 0, I always forget to test for that specific scenario even though I am well aware of it.

pinxi -U

should correct that issue with 3.3.09-09

3.3.09-10 fixes more stepping bugs that led to Intel CPU arch: detection failures in certain cases, always.

Hey there, sorry no update for a bit … but just in case you needed a check again;

$ pinxi -V
pinxi 3.3.09-22 (2021-11-29)

Copyright (C) 2008-2021 Harald Hope aka h2
Forked from Infobash 3.02: Copyright (C) 2005-2007 Michiel de Boer aka locsmif.
Using Perl version: 5.034000

$ inxi -MCazy | curl -F 'file=@-' https://0x0.st        
$ pinxi -MCazy | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy1 | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy --dbg 39 --dbg 8 | curl -F 'file=@-' https://0x0.st

For me the installation method doesn’t work

~ >>> cd /usr/local/bin && sudo wget -O pinxi smxi.org/pinxi && sudo chmod +x pinxi                                                                                                                                                        
--2021-12-02 18:43:34--  http://smxi.org/pinxi
Auflösen des Hostnamens smxi.org (smxi.org)…
Verbindungsaufbau zu smxi.org (smxi.org)||:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://smxi.org/pinxi [folgend]
--2021-12-02 18:43:34--  https://smxi.org/pinxi
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Verbindungsaufbau zu smxi.org (smxi.org)||:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
Platz: https://github.com/smxi/inxi/raw/inxi-perl/pinxi [folgend]
--2021-12-02 18:43:35--  https://github.com/smxi/inxi/raw/inxi-perl/pinxi
Auflösen des Hostnamens github.com (github.com)…
Verbindungsaufbau zu github.com (github.com)||:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
Platz: https://raw.githubusercontent.com/smxi/inxi/inxi-perl/pinxi [folgend]
--2021-12-02 18:43:35--  https://raw.githubusercontent.com/smxi/inxi/inxi-perl/pinxi
Auflösen des Hostnamens raw.githubusercontent.com (raw.githubusercontent.com)…,,, ...
Verbindungsaufbau zu raw.githubusercontent.com (raw.githubusercontent.com)||:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 964958 (942K) [text/plain]
Wird in »pinxi« gespeichert.

pinxi                                                      100%[========================================================================================================================================>] 942,34K  --.-KB/s    in 0,1s    

2021-12-02 18:43:36 (6,22 MB/s) - »pinxi« gespeichert [964958/964958]

/usr/local/bin >>> pinxi -U                                                                                                                                                                                                                
Error 48: The file: pinxi is not writable!
/usr/local/bin >>> inxi -MCazy | curl -F 'file=@-' https://0x0.st                                                                                                                                                                      [48]
zsh: command not found: inxi

I usually change ownership of pinxi in /usr/local/bin to my user, but if you don’t, you have to use sudo or root to update with -U.

Technically it’s irrelevant where you put pinxi, I just find it easier to have in /usr/local/bin so that it’s automatically in PATH, so I don’t have to remember where it is, since I install it on every system I have access to.

It is correct during heavy development to always update pinxi with -U, either with changed ownership, doas, sudo, or root.

But this is pretty simple, download to the directory you want, give it execute permissions, then run it, if the job requires superuser permissions, then use the appropriate options to do that, same as anything else in unix/linux world.

Hi, it was a misunderstanding. I can run the program witht he command pinxi, but not with the command inxi.

~ >>> pinxi -MCazy | curl -F 'file=@-' https://0x0.st      


~ >>> pinxi -MCazy1 | curl -F 'file=@-' https://0x0.st 


~ >>> pinxi -MCazy --dbg 39 --dbg 8 | curl -F 'file=@-' https://0x0.st


ryzen cpus are looking good, working on corner case stuff now, asymmetric architectures, legacy hardware and operating systems, fixing some issues with some ARM SOC cpu topologies.

If I only remembered where I put my VIA Eden thin client…

If only I hadn’t finally given away my 1995 high end pro laptop, still ran, but couldn’t get any data onto it so finally gave up.

The legacy/fallback cases are the most challenging because I have to somewhat preserve the legacy logic in pinxi as fallback for cases with very little good data, bsds, old cpus, very old operating systems, while integrating all the advanced new features. Tricky balance.

On an old Lenovo Mini PC called ideacentre Q150
~ >>> pinxi -MCazy | curl -F 'file=@-' https://0x0.st
~ >>> pinxi -MCazy1 | curl -F 'file=@-' https://0x0.st
~ >>> pinxi -MCazy --dbg 39 --dbg 8 | curl -F 'file=@-' https://0x0.st

Intel Core2 Duo E6750

$ pinxi -MCazy | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy1 | curl -F 'file=@-' https://0x0.st
$ pinxi -MCazy --dbg 39 --dbg 8 | curl -F 'file=@-' https://0x0.st

It is available on AUR: AUR (en) - inxi-perl-git