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: .... 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:
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.