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

[Brickwizard]

OK we are now there.. my 21 yr old travelmate running Antix

brian@antix1:/usr/local/bin
$ inxi -MCazy
Machine:
Type: Laptop System: Acer product: TravelMate 2410 v: 0100 serial: <filter>
Chassis: type: 10 serial: <filter>
Mobo: Acer model: Morar v: Rev serial: <filter> BIOS: Phoenix v: 1.07
date: 09/26/2005
CPU:
Info: Single Core model: Intel Celeron M bits: 32 type: MCP arch: M Dothan
family: 6 model-id: D (13) stepping: 8 microcode: 20 cache: L2: 1024 KiB
flags: pae sse sse2 bogomips: 2992
Speed: 1496 MHz min/max: N/A Core speed (MHz): 1: 1496
Vulnerabilities: Type: itlb_multihit status: KVM: Vulnerable
Type: l1tf status: Vulnerable
Type: mds
status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Type: meltdown status: Vulnerable
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
brian@antix1:/usr/local/bin
$ pnxi -mxazy1
bash: pnxi: command not found
$ pinxi -MCay80
Machine:
Type: Laptop System: Acer product: TravelMate 2410 v: 0100
serial: <superuser required> Chassis: type: 10 serial: <superuser required>
Mobo: Acer model: Morar v: Rev serial: <superuser required> BIOS: Phoenix
v: 1.07 date: 09/26/2005
CPU:
Info: Single Core model: Intel Celeron M bits: 32 type: MCP arch: M Dothan
family: 6 model-id: D (13) stepping: 8 microcode: 20 cache: L2: 1024 KiB
flags: pae sse sse2 bogomips: 2992
Speed: N/A min/max: N/A core: No per core speed data found.
Vulnerabilities:
Type: itlb_multihit status: KVM: Vulnerable
Type: l1tf status: Vulnerable
Type: mds
status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
Type: meltdown status: Vulnerable
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
brian@antix1:/usr/local/bin
$

 

[f33dm3bits]

[if inxi -MCay or -MCay1 gives an error for -y as unsupported, use -MCay80 instead, -y was added I think 3.1, and -y1 maybe 3.2, I forget when]

Okay Mr Mackey!

inxi -MCay
Machine:
  Type: Desktop Mobo: Micro-Star model: MPG Z390 GAMING EDGE AC (MS-7B17)
  v: 2.0 serial: <superuser required> UEFI: American Megatrends v: A.C1
  date: 12/25/2020
CPU:
  Info: 8-Core model: Intel Core i9-9900KF bits: 64 type: MT MCP
  arch: Kaby Lake note: check family: 6 model-id: 9E (158) stepping: D (13)
  microcode: EA cache: L1: 512 KiB L2: 2 MiB L3: 16 MiB
  flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 115232
  Speed: 862 MHz min/max: 800/5000 MHz Core speeds (MHz): 1: 800 2: 1502
  3: 813 4: 1320 5: 1078 6: 911 7: 944 8: 962 9: 824 10: 809 11: 800 12: 800
  13: 800 14: 800 15: 800 16: 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 mitigation: TSX disabled

 pinxi -MCay
Machine:
  Type: Desktop Mobo: Micro-Star model: MPG Z390 GAMING EDGE AC (MS-7B17)
  v: 2.0 serial: <superuser required> UEFI: American Megatrends v: A.C1
  date: 12/25/2020
CPU:
  Info: 8-Core model: Intel Core i9-9900KF bits: 64 type: MT MCP
  arch: Coffee Lake family: 6 model-id: 9E (158) stepping: D (13)
  microcode: EA cache: L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 2 MiB
  desc: 8x256 KiB L3: 16 MiB desc: 1x16 MiB
  flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  bogomips: 7202
  Speed (MHz): avg: 1394 high: 4478 min/max: 800/5000 cores: 1: 800 2: 1192
  3: 800 4: 800 5: 800 6: 4478 7: 3253 8: 2494 9: 1241 10: 809 11: 1200
  12: 1198 13: 852 14: 800 15: 800 16: 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 mitigation: TSX disabled

 

[h2-1]

Note that in fixing another issue, I accidentally broke legacy support for core speeds, I'll have that fixed shortly.

Will then dig into this thread and check everything, but this is taking a lot of work, lol, but at least a lot of bugs are being found and fixed.

Yes, yes, jI hear you raging, finally pinxi and soon inxi have enhanced RiscV support, I know, I know, it's been years coming, but that's what happens when I get an actual real data set and realize I can actually get the stuff working without a lot of work. That's what slowed me down yesterday, that was a big update internally to adopt far better ways of handling the diverse arm/mips/sparc/riscv,ppc risc type cpus, the old way was a bunch of randomly applied hacks which had built up over the years, similar to the CPU core logic.

Broken cpu speed logic should be fixed shortly.

 

[Brickwizard]

Can you run these commands and paste the output somewhere:

~$ for i in $(ls /sys/devices/system/cpu/{cpu*/topology,cpu*/cpufreq,cpu*/cache/index*,smt}/*);do echo -n "$i::";cat $i;done > cpu-sys.txt
ls: cannot access '/sys/devices/system/cpu/smt/*': No such file or directory
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: Permission denied
cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: Permission denied
cat: '/sys/devices/system/cpu/cpu0/cache/index0/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu0/cache/index1/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu0/cache/index2/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu0/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
cat: '/sys/devices/system/cpu/cpu1/cache/index0/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu1/cache/index1/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu1/cache/index2/power:': No such file or directory
cat: async: No such file or directory
cat: autosuspend_delay_ms: No such file or directory
cat: control: No such file or directory
cat: runtime_active_kids: No such file or directory
cat: runtime_active_time: No such file or directory
cat: runtime_enabled: No such file or directory
cat: runtime_status: No such file or directory
cat: runtime_suspended_time: No such file or directory
cat: runtime_usage: No such file or directory
cat: '/sys/devices/system/cpu/cpu1/cpufreq/stats:': No such file or directory
cat: reset: No such file or directory
cat: time_in_state: No such file or directory
cat: total_trans: No such file or directory
cat: trans_table: No such file or directory
mint@mint:~$

pinxi --debug 22 --debug-id brickwizard
Starting pinxi debugging data collector...
Loading required debugger Perl File:: modules...
Debugger data going into:
/home/mint/.local/share/pinxi/pinxi-mint-brickwizard-2021-11-29_220047-3.3.09-16
Note: for dmidecode, smartctl, lvm data you must be root.
----------------------------------------
Collecting audio data...
Collecting bluetooth data...
Collecting dev, label, disk, uuid data, df...
Collecting Xorg log and xorg.conf files...
Collecting X, xprop, glxinfo, xrandr, xdpyinfo data, wayland, weston...
Collecting networking data...
Collecting Perl module data (this can take a while)...
Collecting system data...
Collecting system files data...
----------------------------------------
Constructing /sys ls data...
Building /sys file list...
Parsing /sys files...
----------------------------------------
Constructing /proc ls data...
Building /proc file list...
Adding /proc files...
----------------------------------------
Creating pinxi output file now. This can take a few seconds...
Starting pinxi from: /usr/local/bin/
----------------------------------------
Creating tar.gz compressed file of this material...
File: pinxi-mint-brickwizard-2021-11-29_220047-3.3.09-16.tar.gz
Removing /home/mint/.local/share/pinxi/pinxi-mint-brickwizard-2021-11-29_220047-3.3.09-16...
Directory removed.
----------------------------------------
Uploading to: ftp.smxi.org/incoming
File to be uploaded:
/home/mint/.local/share/pinxi/pinxi-mint-brickwizard-2021-11-29_220047-3.3.09-16.tar.gz
Connected to FTP server.
Uploaded file successfully!
Goodbye.
Removing debugger gz file:
/home/mint/.local/share/pinxi/pinxi-mint-brickwizard-2021-11-29_220047-3.3.09-16.tar.gz
File removed.
Debugger data generation and upload completed. Thank you for your help.

 

[h2-1]

Brickwizard, looking good, the new advanced debuggers are working, those are tricky to use, but seem fine as long as I have the new datasets, which have their feed stock files, I can actually theoretically also generate these file pairs from earlier debugger datasets though it takes a few extra steps. These types of advanced debugger emulations were essentially impossible to do with the previous inxi logic, I could only use the test cpuinfo file, but couldn't get the /sys data, but I designed that in from the start from the first data collector to make sure I could debug complicated issues.

pinxi -Cay --fake cpu
CPU:
  Info: Single Core model: Intel Atom N270 bits: 64 type: MT arch: Bonnell
  family: 6 model-id: 1C (28) stepping: 2 microcode: 208 cache: L1: 56 KiB
  desc: d-1x24 KiB; i-1x32 KiB L2: 512 KiB desc: 1x512 KiB
  flags: ht nx pae sse sse2 sse3 ssse3 bogomips: 3192
  Speed (MHz): avg: 1596 min/max: 800/1600 cores: 1: 1596 2: 1596
  Vulnerabilities:
  Type: meltdown status: Not affected
  Type: spectre_v1 status: Not affected
  Type: spectre_v2 status: Not affected

These fixes just went up, seem to work, though I want to test a few other legacy systems. Not sure if > 1 physical cpu systems will work with this fix, I think they 'should', in 'theory', but need to see it to make sure. For legacy hardware, the main requirement is to never be more wrong than inxi was originally, and ideally, to generally be more right if the data permits.

A single core Atom MT was an ideal test case since it shows me that most of the logic is now working again as expected for legacy systems.

 

[Brickwizard]

as long as your happy.. I dont have anything else in the cupboard to test ,anything else you need from what I have?

edit.. the old acer is a single core celeron would you like me to run de-bug on that?

 

[dos2unix]

pinxi -MCazy1
Machine:
Type: Desktop
Mobo: ASRock
model: X570 Phantom Gaming 4 WiFi ax
serial: <filter>
UEFI: American Megatrends
v: P2.30
date: 01/13/2020

CPU:
Info: 12-Core
model: AMD Ryzen 9 3900X
socket: AM4
bits: 64
type: MT MCP
arch: Zen 2
family: 17 (23)
model-id: 71 (113)
stepping: 0
microcode: 8701013
cache:
L1: 768 KiB
desc: d-12x32 KiB; i-12x32 KiB
L2: 6 MiB
desc: 12x512 KiB
L3: 64 MiB
desc: 4x16 MiB
flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
bogomips: 7599
Speed (MHz):
avg: 2745
high: 4156
min/max: 2200/4672
base/boost: 3800/4650
boost: enabled
volts: 1.1 V
ext-clock: 100 MHz
cores:
1: 2139
2: 2058
3: 3596
4: 3453
5: 2138
6: 2199
7: 2968
8: 3243
9: 3981
10: 2892
11: 2134
12: 2132
13: 2040
14: 2068
15: 3600
16: 3494
17: 2089
18: 2158
19: 2078
20: 4156
21: 3840
22: 3145
23: 2194
24: 2089
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

 

[kc1di]

latest run.

pinxi
CPU: Dual Core Intel Core i5-5300U (-MT MCP-)
speed/min/max: 1116/500/2900 MHz Kernel: 5.4.0-91-generic x86_64 Up: 11m
Mem: 1637.4/7661.5 MiB (21.4%) Storage: 238.47 GiB (6.2% used) Procs: 226
Shell: Bash pinxi: 3.3.09-20
kc1di@kc1di-ThinkPad-T450:/usr/local/bin$ pinxi -MCazy1
Machine:
  Type: Laptop
  System: LENOVO
    product: 20BV000AUS
    v: ThinkPad T450
    serial: <superuser required>
  Chassis:
    type: 10
    serial: <superuser required>
  Mobo: LENOVO
    model: 20BV000AUS
    v: SDK0E50510 WIN
    serial: <superuser required>
  UEFI-[Legacy]: LENOVO
    v: JBET71WW (1.35 )
    date: 09/14/2018

CPU:
  Info: Dual Core
    model: Intel Core i5-5300U
    bits: 64
    type: MT MCP
    arch: Broadwell
    family: 6
    model-id: 3D (61)
    stepping: 4
    microcode: 2F
    cache:
      L1: 128 KiB
        desc: d-2x32 KiB; i-2x32 KiB
      L2: 512 KiB
        desc: 2x256 KiB
      L3: 3 MiB
        desc: 1x3 MiB
    flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
    bogomips: 4589
  Speed (MHz):
    avg: 1040
    high: 1228
    min/max: 500/2900
    cores:
      1: 799
      2: 1210
      3: 1228
      4: 926
  Vulnerabilities:
    Type: itlb_multihit
      status: KVM: Vulnerable
    Type: l1tf
      mitigation: PTE Inversion
    Type: mds
      mitigation: Clear CPU buffers; SMT vulnerable
    Type: meltdown
      mitigation: PTI
    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 generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
    Type: srbds
      mitigation: Microcode
    Type: tsx_async_abort
      mitigation: Clear CPU buffers; SMT vulnerable

 

[h2-1]

I'll go through this thread and let you know, got swamped with feedback, which is a good thing, found a ton of big and little issues, most are now resolved as of 3.3.09-20 but waiting to see if more show up. Will try to get this thread checked completely tomorrow, thanks a lot.

 

[h2-1]

pinxi 3.3.09-21 fixes a lot of issues and small or big glitches and bugs, including a fully revised cpu frequency tool, now much more accurate for lower core count cpus, 4 and under seem to really benefit from the fix in cpu speed logic and where it's located in code execution, now it comes right after a 0.3 second default 'sleep' that lets everything quiet down and more closely reflect the state the computer was at before running pinxi/inxi on it. You'll mainly notice this difference between previous pinxi and current pinxi, less pronounced when comparing current pinxi to inxi however since inxi used a similar though not quite as aggressively optimized pre loader of cpufrequency data.

All looks good, I believe all the inxi issues are corrected now in pinxi, looks like the fixes are catching most of the main issues, only some fringe and corner case stuff left to go now I think, keeping fingers crossed.

Thanks for the data, sorry for the delay getting back, had a lot of feedback, takes a while to process, I have to look up each cpu to confirm the data is right in several key areas. next inxi is looking good, hopefully we can catch a few last corner cases and bugs with the redo, and maybe some super legacy stuff too, but a lot has been caught now.

-----------------------------------------

stan, model: 11th Gen Intel Core i7-11700 looks good, everything working.

AMD Phenom II X4 810 looks good.

Intel Core2 6400 looks good.

Intel Core i7-6600U, never thought I'd see surface pro data, heh. That's another one that inxi was getting wrong and pinxi is getting right now.

Intel Core i7-4500U, another one inxi was getting wrong, and pinxi right

AMD A6-9220e RADEON R4 5 COMPUTE CORES 2C+3G, another one with wrong inxi cache, too little in this case, but same cause. All these are correct now in pinxi.

Intel Pentium N3540, that one I think shows the pre-cpu speed fix, notice how one of the cpu cores is spiked all the way almost? Also wrong cache, inxi was wrong much more than I realized, this is somewhat dismal, all correct now in pinxi however.

AMD E1-1200, I think that's the first bobcat arch I've seen so far. cache wrong in inxi there too, you're batting a 1000!!! Certainly highlights how necessary this fix was.

-----------------------------------------

brickwizard, Intel Core i5-4590S is a good example of the broken inxi cache data.

Pentium T4500 had incomplete arch, corrected in current pinxi, actually is Core Penryn, not Penryn

Intel Atom N270 had an odd result for system type, it means something glitched but probably on the system data side, not inxi's side.

Intel Celeron M acer suffered from a brief pinxi legacy speed handler bug, that is corrected in current pinxi
That one looks like it didn't get much from /sys, not the cache, and not the speed probably I'd guess. those issues are or should be resolved in current pinxi latest. Note that the updates remove the attempt to guess what cache cpuinfo is referring to with its ambiguous 'cache size: ' item, which I have now seen refer to: L1 cache, L2 cache (with L3 present), L2 (with no L3), or L3. It's completely impossible to guess which it was, so any attempt when fallback cache is used is now removed, and you'll just see: cache: [size] in the output, nothing about L1,L2,L3, that means inxi only got the vague item from cpuinfo. On those systems, however, if you run inxi as root or sudo, it will get the data, which is usually, but not alway, right, from dmidecode.

-----------------------------------------

kc1di, Intel Core i5-5300U is a good example of the cache bug, works fine now in pinxi as you can see.

-----------------------------------------

Condobloke, Intel Pentium G4400, almost all the cpu caches in inxi are wrong!! I guess this shows why this fix had to be done.

-----------------------------------------

f33dm3bits, looks like you ran pinxi on Intel Core i9-9900KF after the bug fix for bad ID of intel cpu architectures, that was an old bug, corrected before you grabbed your pinxi, good to see it working. That's why it reported as kaby lake in inxi, but correctly as coffee lake in pinxi. That is an old bug, been around a long time, glad to have found and fixed it.

-----------------------------------------

dos2unix, the AMD Ryzen 9 3900X you have is another one inxi would always have gotten wrong, now correct in pinxi. That's a good example of a cpu that inxi was getting badly wrong.

-----------------------------------------

 

[h2-1]

note that pinxi 3.3.09-30 is closer to final beta testing now, it's significantly changed and improved, finally got one of the last troublesome areas worked out:

CPU:
  Info: model: AMD Ryzen 5 2600 socket: AM4 bits: 64 type: MT MCP arch: Zen+
  family: 17 (23) model-id: 8 stepping: 2 microcode: 8008204 bogomips: 6799
  Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 cache: L1: 576 KiB
  desc: d-6x32 KiB; i-6x64 KiB L2: 3 MiB desc: 6x512 KiB L3: 16 MiB
  desc: 2x8 MiB
  Speed (MHz): avg: 2338 high: 3673 min/max: 1550/3400 base/boost: 3400/3900
  boost: enabled volts: 1.1 V ext-clock: 100 MHz cores: 1: 3673 2: 1916
  3: 3648 4: 3292 5: 2805 6: 2438 7: 1521 8: 2188 9: 1388 10: 1408 11: 1560
  12: 2220
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:

Note the new line, Topology:, that appears with -Ca unless very legacy Linux, BSD, or using --force cpuinfo to somewhat emulate legacy behavior and bypass the new /sys logic.

pinxi -C
CPU:
  Info: 6-core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP cache:
  L2: 3 MiB
  Speed (MHz): avg: 3038 min/max: 1550/3400 cores: 1: 1936 2: 3886 3: 2028
  4: 3224 5: 2368 6: 3898 7: 3899 8: 2581 9: 3840 10: 3462 11: 3024 12: 2314

Many other things were changed and made slightly more coherent, consistent, and logical, now for example Flags: always appears after speeds, regardless of whether -f or -Cx is used, that was an odd behavior legacy inxi has had for reasons that escape my memory. I think it might have been the original requirement to have basic outputs be as short re total lines as possible due to IRC use, which was heavy for IRC originally, it was actually first and primarily an IRC tool, second a forum/end user/sys admin tool, basically the reverse of what it is today.

The more observant of you may notice that the Topology: item has been returned, that was removed initially because Topology: as line starter only applied to the first item in the line, which made no sense, and it wasn't accurate or correct. Now the Topology line refers to the cpu topology, and only that, re cores, threads, threads per core, caches, different physical cpu type structures, etc.

Three new 'type:' items also have been added, those appear in pinxi, pinxi -b, and pinxi -C, those are AMP (Asymmetric Multi Processing, aka, 2 or more physical cpus that are not identical, common with ARM SOC devices, which may have different core counts per cpu, and different min max speeds, which will also show in that case in Topology: line as well per variant), MST (Multi Single Threaded, so far only Intel Alder Lake will have cores that are either single or multi threaded in same physical cpu), AMCP (Asymmetric MultiCore Processor, like Alder Lake, that is, within one physical processor, two types of core complexes are running, alder lake has 8 single threaded 'efficiency cores', and 4 -to 8 2 threaded 'performance cores', and pinxi will also show how many of each type was detected in the Topology line.

Other fairly significant optimizations are the speeds now reflect much better the underlying base speed of the system BEFORE you ran pinxi/inxi on it. This difference is quite striking on some hardware and cpus, with the new method, the cpu cores will report speeds often quite near their total resting state, but on inxi, will be quite spiked.

There's a few small bugs still being worked on, but this is quite close to what the final version will look and act like.

This version is significantly optimized, resulting in many systems running pinxi -Ca a bit faster than inxi -Ca, or almost the same speed, despite pinxi doing a lot more work and having more code. Note that with -Ca caches move to topology, which is what they really belong to.

You can time the difference like so:
time pinxi -C
time inxi -C

time inxi -Cy
CPU:
  Info: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP cache: L2: 3 MiB
  Speed: 3657 MHz min/max: 1550/3400 MHz Core speeds (MHz): 1: 3657 2: 3899
  3: 2675 4: 1853 5: 3232 6: 2755 7: 2595 8: 3679 9: 1927 10: 1574 11: 2094
  12: 3815

real    0m0.701s
user    0m0.169s
sys    0m0.044s

time pinxi -C
CPU:
  Info: 6-core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP cache:
  L2: 3 MiB
  Speed (MHz): avg: 2390 min/max: 1550/3400 cores: 1: 1844 2: 2835 3: 2695
  4: 2093 5: 3755 6: 2893 7: 2105 8: 3162 9: 2617 10: 1605 11: 1685 12: 1392

real    0m0.683s
user    0m0.152s
sys    0m0.038s

I find these time differences quite consistent, but also hardware dependent, some ARM run slower for example for pinxi than inxi, but in general, most real hardware seems to run pinxi either a bit faster, or about the same, as inxi, which is quite good considering how much more code and logic has for CPUs than inxi had. For basic ARM cpus, I suspect the slower pinxi speed comes from not having level 1 instruction cache, since pinxi -C is running a LOT more instructions than inxi is, so if those aren't being cached right next to the core, there's going to be a significant slowdown.

Feel free to take out for a spin, and post results.

 

[Brickwizard]

Ok. just ran pinxi on my HP, cpu and mb temps look far too low [around 29C I would expect it to be around 50C]

 

[h2-1]

temps are a different issue, if you give me the output of sensors in a file (sensors > sensors.txt), or just shoot off a --debug 22 data set I can look at those. Sensors is easy to debug currently, though maybe not in the future if I switch to using /sys based sensors data.

 

[h2-1]

Oh, I forgot, I finally changed the default widths of pinxi/inxi to 80 columns (-y width) because I'm just seeing far too many forum, issue, bug reports that paste in inxi output which wraps all over the place and looks absolutely terrible, and makes me look bad lol since it looks like inxi output is crap when you paste it from a wide terminal into a narrow display like a forum post, with sidescrolling, or just too narrow, like many issue posts, like linux kernel, ubuntu, etc.

Basically this default won't be changed because it's actually not primarily designed to benefit the user themselves, it's designed to benefit anyone who might need to read and parse the inxi output, I've thought about that change for a long time, I thought using -y would catch on and people would get it, but it just never happened, so I decided that it was time to default to always readable width and output formatting.

 

[Brickwizard]

de bug results sent

 

[Brickwizard]

not in the office now,,, just run pinxi on the dell lappy, temp report fine on this one just over 52C

 

[h2-1]

Thanks. this is a standard sensors issue, there are two sensors arrays, acpitz-acpi-0 and coretemp-isa-0000, inxi is giving preference to the acpitz array since historically that has tended to be more accurate and reflect the overall state of the cpu temp. Not in your case however. core temp is usually used only as a fallback because those are the actual on core temperatures per core, which tend to be much hotter than the overall cpu, and also vary as you can see widely by core.

to get around issues like this, inxi supports an option and configuration item to force use of whichever sensor array you want, if you pick coretemp it will then default to using Core 0: temp.

But it can't actually 'know' which you want to use currently, that logic is difficult, and is one reason almost all sensors desktop widgets make you manually pick which sensor array you want to use, there's no actual way to 'know' which is the right one.

If the sensor values are labeled well, like CPU Temp:, then inxi will always pick that one first, but if it only finds, as in your case, temp1:, then Core 0:, it will always default to using temp1: first, and Core 0: only if nothing else was found.

pinxi -s --sensors-use coretemp-isa-0000

I think that's the syntax, believe it requires the full string

Note that there is NEVER a default that is 'right' for sensors, and there never has been, the only way it could be right is if the systems internally had always without exception translated the 'right' sensor value for overall cpu temp to something like: CPU 0: temp.

Some sensors configurations do that, and users can configure the names to be what they want, which then introduces more chaos into the data inxi has to handle.

It's a pure guessing game, inxi got I think to about 95% or so right, which took a ton of work, and ongoing fixes, to guess 'right' most of the time, but it's all pure guessing, as far as I know, no sensors apps actually do this guessing, they make you assign the sensors you want to see, period. The ones I have used show zero data until you tell it what sensors to use, what values from each sensors to use for what, etc.

Inxi is actually no different, in that you can also tell it which sensors you prefer for your data, but it is different in that it will try to make a guess as to what the likely decently 'right' data is.

Sensors are one of the biggest ongoing messes in linux, that's primarily because a lot of the motherboard makers do NOT release their sensors specs to the linux kernel guys, they will usually only release 1 sensor, the cpu temp, then it drops from there rapidly. And those are released usually only under NDA to the kernel guys just so they can show the cpu temp.

That's why windows sensors tend to be radically better than linux, it's not because the kernel guys can't do the work, it's because they aren't being allowed to do the work due to non free proprietary nonsense which shouldn't exist in 2021 but does.

 

[stan]

Which -options would you like run with pinxi? Or is a --debug 22 report better?

 

[Brickwizard]

I have always gone by the cpu temp as this is the one most often quoted in work manuals, and being an old fellah building and repairing boxes I got use to looking for a cpu temp of around 50-60 for lappies and 50-70 for desktops and panic if it past 75

Brian

 

[h2-1]

brickwizard, there is no sensor that is 'cpu temp', that's an illusion. What actually exists is generally non documented sensor arrays, whose data can only very painfully be reverse engineered to map to identifiable values.

What you see in 'sensors' output is a result of that reverse engineering in most cases. A small handful of motherboard makers do release the specs to these sensors to the kernel guys, and you can always tell that because a new board running a new kernel will have full sensors output. Very rare.

Technically, what exists in /sys is a set of hardware monitor directories, each one is I believe one array if I remember right, and when the sensors are known and mapped to known types, you will see that it is a temp1 sensor, with a label of something if a label has been assigned, usually by the lm sensors kernel guys, or a fan1 sensor and its value.

My board, a gigabyte ryzen, for example, has never had any real sensors data available, basically if you want real sensors data, you have to buy a board vendors that releases those specs, or where the board has been reverse engineered by enthusiasts.

sensors are not what you think under the covers, few have any idea of the near heroic work the linux kernel sensors guys have done over the decades now.

If you see something like CPU: temp, that is a label that has been applied to say, temp1: and then sensors output shows CPU: temp item, but those are all just strings that are being matched if the rules were created. There is no internal 'CPU Temp' sensor, that doesn't exist, never has. There's an array of sensors, which stream data to the kernel, some of that data is recognized and mapped to specific values and fields and outputs, much of it is totally unknown.

sensors is one of the biggest messes in linux today sadly, and always has been, though they are MUCH better now than they were before, when you had to configure lm-sensors on which sensors to use, now you don't even need to use lm sensors, but you do need to know which label and sensor type applies to what device.

And those are only the sensors where the data has been mapped to something like fan1, temp1, wattage, etc, the bulk of most standard motherboard sensors are not mapped, and most are unlikely to ever be mapped because it takes forever to do that mapping, and it's done by volunteers. If the data has not been mapped, it's just a random series of 1s and 0s, I don't know exactly how sensors data exists on the system, but it's not nearly what people think after they configure manually their sensors program to show the sensor array they want to use.