Re: cpu-x

On 5/17/2024 4:23 PM, vallor wrote:

On Fri, 17 May 2024 09:43:28 -0400, DFS <nospam@dfs.com> wrote in
<66475efb$0$7180$882e4bbb@reader.netnews.com>:
 

On 5/17/2024 12:14 AM, vallor wrote:

On Wed, 15 May 2024 10:14:26 -0400, DFS <nospam@dfs.com> wrote in
<6644c341$0$2363136$882e4bbb@reader.netnews.com>:
>

On 5/15/2024 10:04 AM, vallor wrote:

On Wed, 15 May 2024 09:47:02 -0400, DFS <nospam@dfs.com> wrote in
<6644bcd4$1$2363139$882e4bbb@reader.netnews.com>:
>

On 5/15/2024 1:48 AM, Lawrence D'Oliveiro wrote:

On Wed, 8 May 2024 10:08:21 -0400, DFS wrote:
>

But HWiNFO is a serious hardware info app, with extreme detail
about every component, including the BIOS.

>
<https://manpages.debian.org/8/biosdecode.en.html>

>
>
$ sudo biosdecode -d /dev/mem # biosdecode 3.3 ACPI 2.0 present.
            OEM Identifier: VRTUAL RSD Table 32-bit Address:
            0x00100000 XSD Table 64-bit Address: 0x0000000000100000
>
>
This is on Ubuntu WSL.

>
Now, I know you're not that stupid.
>
Who do you think you're fooling?

>
>
OPTIONS -d, --dev-mem FILE Read memory from device FILE (default:
/dev/mem)
>
>
What 'not that stupid' results do you get?

>
I don't know "biosdecode" from Adam.
>
But I do know dmidecode -- let us examine the "well-formatted"
output!
>
[...]
Handle 0x0010, DMI type 4, 48 bytes Processor Information
Socket Designation: SP3r2 Type: Central Processor Family: Zen
Manufacturer: Advanced Micro Devices, Inc.
ID: 10 0F 83 00 FF FB 8B 17 Signature: Family 23, Model 49,

Stepping 0

Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported) PAT (Page

attribute

table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
HTT (Multi-threading)
Version: AMD Ryzen Threadripper 3970X 32-Core Processor Voltage:

1.1 V

External Clock: 100 MHz Max Speed: 4550 MHz Current Speed: 3700

MHz

Status: Populated, Enabled Upgrade: Socket SP3r2 L1 Cache Handle:
0x000D L2 Cache Handle: 0x000E L3 Cache Handle: 0x000F Serial

Number:

Unknown Asset Tag: Unknown Part Number: Unknown Core Count: 32

Core

Enabled: 32 Thread Count: 64 Characteristics:
64-bit capable Multi-Core Hardware Thread Execute

Protection Enhanced

Virtualization Power/Performance Control
[...]

>
weak.  Get HWiNFO or AIDA64 for real hardware listings.
>
>

And as I said, they ported it to Windows -- so run dmidecode in an
admin shell (not WSL -- command.com)
and let's see what that looks like, hmm?

>
https://gnuwin32.sourceforge.net/packages/dmidecode.htm
https://www.nongnu.org/dmidecode/
>
I downloaded the Win binaries from the first link and extracted them:
>
Directory of C:\Users\DFS\Desktop
>
12/03/2008  03:30 PM            19,968 biosdecode.exe 05/17/2024  07:51
AM           368,567 dmidecode-2.10-src-setup.exe 12/03/2008  03:30 PM
          80,896 dmidecode.exe 12/03/2008  03:30 PM            16,384
ownership.exe 12/03/2008  03:30 PM            18,944 vpddecode.exe
                 5 File(s)        504,759 bytes 0 Dir(s)  153,200,242,688
                 bytes free
>
C:\Users\DFS\Desktop>biosdecode # biosdecode 2.10
>
C:\Users\DFS\Desktop>ownership
>
C:\Users\DFS\Desktop>vpddecode # vpddecode 2.10
>
So 3 of the 4 did nothing.

 Did you run them with administrator permissions?
 

>
$ dmidecode just printed BIOS info

 Did you run them with admin perms?

I just did, and got the same results.

Note that the bare-bones output from Linux itself for the processor
features can be found by just catting /proc/cpuinfo:
>
_[/root]_(root@lm)⭕_
# cat /proc/cpuinfo | head -28 processor : 0 vendor_id :

AuthenticAMD

cpu family : 23 model : 49 model name : AMD Ryzen

Threadripper 3970X

32-Core Processor stepping : 0 microcode : 0x8301039 cpu

MHz :

2200.000 cache size : 512 KB physical id : 0 siblings : 64 core

id : 0

cpu cores : 32 apicid : 0 initial apicid : 0

fpu : yes fpu_exception

: yes cpuid level : 16 wp : yes flags : fpu vme

de pse tsc msr pae

mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2
ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good
nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni
pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave
avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core
perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd
mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed
adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr
rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean
flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload
vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es bugs
: sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass retbleed
smt_rsb srso bogomips : 7400.42 TLB size : 3072 4K pages

clflush size :

64 cache_alignment : 64 address sizes : 43 bits physical, 48

bits

virtual power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
[... repeat 63 more times]
>
You can't expect the kernel itself to be too flashy with its output.

>
>
Printing meaningful descriptions in sorted order isn't 'flashy', and
should be expected.  But the powers that be decided not to:
>
https://docs.kernel.org/arch/x86/cpuinfo.html
>
>

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

"The list of feature flags in /proc/cpuinfo is not complete and
represents an ill-fated attempt from long time ago to put feature flags
in an easy to find place for userspace.
...
Regarding implementation, flags appearing in /proc/cpuinfo have an
X86_FEATURE definition in arch/x86/include/asm/cpufeatures.h."
>

-------------------------------------------------------------------------
 This is as far as I read in your original message.  I see now
that you added more:
 

>
If you look at cpufeatures.h (and at the shell script that extracts the
flags - arch/x86/kernel/cpu/mkcapflags.sh), you see it's a minor code
change to extract the flag description along with the flag, and sort and
output the data correctly.
>
But doing it right would also require someone to maintain the entries in
cpufeatures.h.  Sounds like a job for YOU, who made big money with
Linux.  Time to give back.

The cpufeatures.h found at
https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/cpufeatures.h
has already been updated since the one included with kernel 6.8.6, so someone IS maintaining it.  Both names on the page work at Intel.
 > I'm already testing Linux with the Nvidia open drivers, and just
 > helped pan(1) out by submitting a ticket for gmime regarding the
 > Newsgroups: header -- which was acted on.>

I don't need to be goaded into another project with the
purpose of satisfying some wintroll's aesthetics
regarding CPU feature output.
 (But I've tucked it into the back of my mind as something to look
at, perhaps as a separate perl tool to show others[*] how its done.)
 [*] Like rando wintrolls

perl will hardly be any better than the inscrutable shell script mkcapflags.sh.  It needs to be replaced with well-commented python.
The kernel docs say "Users should rely on tools like tools/arch/x86/kcpuid and cpuid(1)."
I tried cpuid -1  (info for only one processor).  It output an incredible amt of info, 816 lines, but it looks like a bitch to parse.