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.

Code:# 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 pinxiFirst 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:

Code:inxi -MCazy
Machine: ....
CPU:
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: ....
CPU:
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:
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
cores:
1: 2000
2: 2000
3: 2000
4: 2000
5: 2000
6: 1997
7: 1609
8: 1204
9: 1207
10: 1242
11: 1383
12: 1552
Vulnerabilities:
....

# Another sample of the new logic:
# which will show something like this:
pinxi -MCazy1
Machine:
......
CPU:
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
cache:
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
cores:
1: 3326
2: 2746
3: 1454
4: 1468
5: 3895
6: 3891
7: 2674
8: 2783
9: 1559
10: 1556
11: 3475
12: 3783
Vulnerabilities:
.....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:

Code:pinxi -MCay1 --force cpuinfoNote 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:

Code:pinxi -MCazy --dbg 39 --dbg 8will 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, and any ARM SOC that uses two different CPU blocks, with different speeds per block.