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.