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

h2-1 · 11-27-2021, 06:54 PM

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

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

Code:

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, and any ARM SOC that uses two different CPU blocks, with different speeds per block.

igadoter · 11-27-2021, 07:24 PM

You must be crazy. Am I supposed to run your ixi fix whatever as root? Script or binary from unknown source? Debian testing is unimpressive. You should post something more convincing.My advice for you is go away and you know what.

You are lucky I am in forgiving mood. Most I can't stand is stupidity. [removed].

h2-1 · 11-27-2021, 07:31 PM

Cut your paranoia, I've been here many times, get a clue. Learn how to do forum (or better, internet) searches, and you'll find I do this fairly routinely, over the years. Obviously you missed all those times however. Or, even better, search the forums for pinxi and me, and then delete your post and just move on. If you can't forgive stupidity, then stop being stupid, for christ's sake.

You don't have to install this as root, if you don't want, it's just more convenient. And you certainly don't need to run this as root, in fact, I prefer you don't for this test.

Again, try not to derail a bug catching thread and find something else to do, please. I tend to post on the slackware for this testing because, usually (but not always, obviously, in this case) the people here are very good. Try not to embarrass them any further please since I tend to respect the people here, most of them anyway. If you can't contribute positively, then just find something else to do, I have better things to do with my time, really.

Patrick Volkerding must be really confused since he packages inxi, the stable version, pinxi being the development version, in core slackware, which you'd know if you had bothered checking before typing and hitting enter.

igadoter · 11-27-2021, 07:53 PM

You have only seven threads on this forum all about testing your creations. So again tell you: go and find some enough poor guys some other place. Locate yourself on gpg server, sign your software then we can talk. For now just goodbye.

h2-1 · 11-27-2021, 07:57 PM

So you're going away now? Good. I'll wait for the real people to show up. Find something else to troll please, I'm not in the mood. I don't need to post often because I only do big changes occasionally (they take a lot of work and time, which if you had any clue about what free software involves, you'd respect), and when I do, I don't like wasting time in the testing phase, like you are wasting mine right now. At least you can count, that's a good sign. And when I do post here, the results and people here have been excellent, which is why I come back. Except for you, so why not admit your mistake and leave quietly before you look even more ridiculous than you already do?

igadoter · 11-27-2021, 08:01 PM

For this kind of stuff you should be banned from LQ forever.

h2-1 · 11-27-2021, 08:04 PM

Sigh. I have had such good experiences here, so positive, so valuable, helping contribute to the overall quality of the features, often able to get slackware features and support in before the new slackware's even come out, yet here, today, you show up, and are dead set on ruining it for everyone. Sad. Really sad. And obviously you won't admit your error, and will just spin around in your little world of anger and frustration rather than apologize and leave this thread alone. Again, if you have nothing positive to contribute, then move on. How can I say it more clearly?

igadoter · 11-27-2021, 08:53 PM

So why at all did you comee here? Asking people to test your work? Wrong forum, I am afraid. Allow us to identify you and things will be ok. Put your work on github or any other public repository. Common stuff. There is nothing more than your posts about tests your work.

Besides if there are so naive people here to just download any trash and run as administrator this trash - as well they can publish openly numbers of their credit cards on internet. And walk naked the streets.

h2-1 · 11-27-2021, 09:02 PM

I come here because the people are good. Your total inability to admit your mistake just keeps making it worse. I come here because, with one exception, you, the feedback and results have been excellent. That is, it has been worth my time, my free, volunteer, developer time, which means something to me, but obviously not to you. Also because I like and respect Slackware, and Patrick Volkerding, and all the users, except you, I've run into here. Why can't you just drop this, turn off your angry ego, and realize you made a mistake, which is fine, we all make them. Try growing as a human, instead of spinning around your issues and anger, they are not interesting to me at all, they do not forward the user needs, they do not forward my volunteer time, it's just your toxic energy looking for a response. I'm not interested in whatever issues you have, I've done this stuff to long to be interested, I'm sorry.

The problem here is not me, and it is not slackware users on this forum, it's 100% you. I can't fix this problem for you, I'm very sorry that I can't, and I'm also sorry for the good users here. Obviously the inxi/pinxi stuff is on github, which you'd know if you'd actually do a second of searching, but your ego is just spinning out of control here, and seems unable to really stop itself, which is sad, as I said, but not my problem. I also recognize that every project and community has at least one toxic individual involved, and if you are that one, but I honestly don't care if you are or not, then I will not judge the others here by your behavior and attitude. I've done this long enough to know how this stuff works.

There have been cases where some distro forums were so toxic top to bottom that I stopped using them as a resource, but I have never, not once, until today, had that issue here with slackware users, who I consider on average quite adult, generally highly competent, non-troll-like, and overall quite pleasant to deal with. If this is a strange concept to you,, then maybe you have to learn something about human behavior.

ZhaoLin1457 · 11-27-2021, 09:02 PM

Quote:

Originally Posted by igadoter

So why at all did you comee here? Asking people to test your work? Wrong forum, I am afraid. Allow us to identify you and things will be ok. Put your work on github or any other public repository. Common stuff. There is nothing more than your posts about tests your work.

Besides if there are so naive people here to just download any trash and run as administrator this trash - as well they can publish openly numbers of their credit cards on internet. And walk naked the streets.

Igadoter, did you are aware that you talk this trash with the INXI's developer?

INXI is now part of Slackware 15.0 RC2, so I believe that its developer is entitled to ask the eventual users of it for further testing of new features.

h2-1 · 11-27-2021, 09:12 PM

Finally, a real user, I would love to delete all the above posts that were pulled off topic and deal with healthy adults, which is why I come here.

And you are absolutely right ZhaoLin1457, this is a HUGE change set, and is going to impact a lot of stuff potentially, so I want to make sure I catch and fix any bugs before it goes into next inxi. This is probably the biggest change to CPU logic in inxi since it was created in 2008 I believe, designed to handle all the failure cases it was having, as well as all the coming highly advanced and complicated cpu's like Alder Lake (inxi was completely incapable of correctly dealing with alder lake type architectures, and was also wrong in several ways quite consistently, particularly with Intel CPUs), and I believe maybe Zen 4 may share some of these very complicated architectures, plus possibly M1 if they get Linux running on it, not to mention various complicated SOC ARM devices.

And I definitely want to see if slackware users can find any problems or bugs, I already found one from another forum, so that's good, it was a subtle small one, but it's already fixed. Most issues will be highly specific to the actual hardware CPU and its data and configuration, since the general logic seems good so far, relatively anyway.

The idea here is to be part of the solution not part of the problem, the solution being able to offer the best and most accurate information for slackware users, particurly given slackware 15 is already in the RC2 phase.

I'm hoping for to get inxi out in a few days, it's been a very tiring development process, a lot of research, had to read kernel patches and comments, obscure issue reports from other things that needed also to know what the cpu is really doing, because so much of this is not well documented outside the kernel code.

drgibbon · 11-27-2021, 09:41 PM

@h2-1 I will check this out later on when I get some time.

@igadoter OP is the developer of inxi, which is included in Slackware.

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

Slackware64 -current. I'm afraid I don't have anything particularly exotic, but there might be a small error for my laptop; cpu-world says it's Comet Lake, not Kaby Lake. Stepping is probably V0 rather than C (but I'm not sure what the difference actually is there). Other than that, though, the L* sizes, etc. are correct:

Code:

 $ inxi --version | grep ^inxi
inxi 3.3.06-00 (2021-07-21)
 $
 $ inxi -MCazy
Machine:
  Type: Laptop System: Dynabook product: dynabook P1-C7MP-BL v: P1C7MPBL
  serial: <filter>
  Mobo: Dynabook model: DBIINV00 v: Type2 - Board Version serial: <filter>
  UEFI: Insyde v: 1.90 date: 08/28/2020
CPU:
  Info: Quad Core model: Intel Core i7-10510U bits: 64 type: MT MCP
  arch: Kaby Lake note: check family: 6 model-id: 8E (142) stepping: C (12)
  microcode: EA cache: L2: 8 MiB
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 36799
  Speed: 835 MHz min/max: 400/4900 MHz Core speeds (MHz): 1: 835 2: 700 3: 700
  4: 700 5: 700 6: 700 7: 704 8: 745
  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
 $
 $ pinxi -MCazy1
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: Kaby 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: 887
    high: 1487
    min/max: 400/4900
    cores:
      1: 1487
      2: 800
      3: 723
      4: 890
      5: 800
      6: 800
      7: 800
      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

And an AMD machine, which looks OK:

Code:

 $ inxi --version | grep ^inxi
inxi 3.3.06-00 (2021-07-21)
 $
 $ inxi -MCazy
Machine:
  Type: Desktop Mobo: Micro-Star model: B450 TOMAHAWK MAX (MS-7C02) v: 1.0
  serial: <filter> UEFI: American Megatrends v: 3.70 date: 06/09/2020
CPU:
  Info: 8-Core model: AMD Ryzen 7 3800X bits: 64 type: MT MCP arch: Zen 2
  family: 17 (23) model-id: 71 (113) stepping: 0 microcode: 8701021 cache:
  L2: 4 MiB
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  bogomips: 124802
  Speed: 2199 MHz min/max: 2200/3900 MHz boost: enabled Core speeds (MHz):
  1: 2199 2: 2198 3: 2200 4: 2199 5: 2198 6: 2199 7: 2200 8: 2198 9: 2200
  10: 2199 11: 2200 12: 2928 13: 2199 14: 2198 15: 2198 16: 2200
  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
  mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP:
  conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
 $
 $ pinxi -MCazy
Machine:
  Type: Desktop Mobo: Micro-Star model: B450 TOMAHAWK MAX (MS-7C02) v: 1.0
  serial: <superuser required> UEFI: American Megatrends v: 3.70
  date: 06/09/2020
CPU:
  Info: 8-Core model: AMD Ryzen 7 3800X bits: 64 type: MT MCP arch: Zen 2
  family: 17 (23) model-id: 71 (113) stepping: 0 microcode: 8701021 cache:
  L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB
  L3: 32 MiB desc: 2x16 MiB
  flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  bogomips: 7800
  Speed (MHz): avg: 2167 high: 2202 min/max: 2200/4559 boost: enabled cores:
  1: 2154 2: 2124 3: 2197 4: 2202 5: 2200 6: 2200 7: 2199 8: 2200 9: 2056
  10: 2054 11: 2176 12: 2130 13: 2199 14: 2195 15: 2200 16: 2199
  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
  mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP:
  conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected

bw42 · 11-27-2021, 09:48 PM

When I run it on my workstation I see an error.

Code:

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

Illegal hexadecimal digit '.' ignored at ./pinxi line 10597.
Illegal hexadecimal digit '.' ignored at ./pinxi line 10597.
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) (2)
    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: 2382
    high: 3800
    min/max: 2166/3800
    boost: enabled
    cores:
      1: 2233
      2: 2166
      3: 2166
      4: 2433
      5: 2166
      6: 2166
      7: 2166
      8: 2166
      9: 2166
      10: 2166
      11: 2166
      12: 2166
      13: 2166
      14: 2166
      15: 2166
      16: 2166
      17: 2166
      18: 2166
      19: 2166
      20: 2166
      21: 2166
      22: 2166
      23: 2166
      24: 2166
      25: 3800
      26: 3800
      27: 3800
      28: 3800
      29: 2183
      30: 2183
      31: 2183
      32: 2183
  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

bw42 · 11-27-2021, 09:49 PM

This is from my Aarch64 server.

Code:

Machine:
  Type: Desktop
  System: SolidRun
    product: SolidRun CEX7 Platform
    v: Rev 1
    serial: N/A
  Chassis:
    type: 6
    v: HoneyComb
    serial: <filter>
  Mobo: N/A
    model: N/A
    serial: N/A
  UEFI: EFI Development Kit II / SolidRun
    v: EDK II
    date: Jul 29 2021

CPU:
  Info: ERR-103
    model: N/A
    socket: BGA-1156
    bits: 64
    type: UP
    arch: ARMv8
    family: 8
    model-id: 0
    stepping: 3
    cache:
      L1: 1.2 MiB
        desc: d-16x32 KiB; i-16x48 KiB
      L2: 8 MiB
        desc: 8x1024 KiB
      L3: 8 MiB
        desc: 1x8 MiB
    bogomips: 0
  Speed: N/A
    min/max: N/A
    base/boost: 2000/2200
    volts: 0.0 V
    ext-clock: 100 MHz
    core: No per core speed data found.
  Features: aes asimd cpuid crc32 evtstrm fp pmull sha1 sha2
  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: __user pointer sanitization
    Type: spectre_v2
      mitigation: Branch predictor hardening
    Type: srbds
      status: Not affected
    Type: tsx_async_abort
      status: Not affected