Empty Vendor & Product, and wrong CPU info on the System Info page

[d19dotca]

Hello,

I recently migrated to a new dedicated server at OVH, and I noticed the Vendor and Product are reading as empty and the CPU reads as 32 Core "AMD EPYC 7351P 16-Core Processor" when it should really be reading as AMD EPYC 7351P 16-Core Processor. I'm not sure where the "32 Core" part comes from as it's a 16-core CPU rather than 32.

With it detecting 32 cores for some reason, it's unfortunately also showing a bad graph as it's based on 3200% instead of 1600%, so all the lines are so short now and almost hard to view.

FWIW, it's a dedicated server from OVH with the product name of "SYS-6-SSD-128" in case you want to confirm the specifications from there too.

Is this a bug in how the data is detected, or perhaps something unique to how OVH dedicated servers generate the details? How does Cloudron identify a Vendor or Product out of curiosity?

[d19dotca]

Some more output in case it helps from my server:

$ lscpu
Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         43 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  32
  On-line CPU(s) list:   0-31
Vendor ID:               AuthenticAMD
  Model name:            AMD EPYC 7351P 16-Core Processor
    CPU family:          23
    Model:               1
    Thread(s) per core:  2
    Core(s) per socket:  16
    Socket(s):           1
    Stepping:            2
    Frequency boost:     enabled
    CPU max MHz:         2400.0000
    CPU min MHz:         1200.0000
    BogoMIPS:            4790.88
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht sy
                         scall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd
                         _dcm 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 skinit wdt t
                         ce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate ssbd ibpb vmmcall fsgsbase bm
                         i1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 clzero irperf xsaveerptr ar
                         at npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold a
                         vic v_vmsave_vmload vgif overflow_recov succor smca sme sev sev_es
Virtualization features: 
  Virtualization:        AMD-V
Caches (sum of all):     
  L1d:                   512 KiB (16 instances)
  L1i:                   1 MiB (16 instances)
  L2:                    8 MiB (16 instances)
  L3:                    64 MiB (8 instances)
NUMA:                    
  NUMA node(s):          4
  NUMA node0 CPU(s):     0-3,16-19
  NUMA node1 CPU(s):     4-7,20-23
  NUMA node2 CPU(s):     8-11,24-27
  NUMA node3 CPU(s):     12-15,28-31
Vulnerabilities:         
  Gather data sampling:  Not affected
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Retbleed:              Mitigation; untrained return thunk; SMT vulnerable
  Spec rstack overflow:  Mitigation; safe RET
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Retpolines, IBPB conditional, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
  Srbds:                 Not affected
  Tsx async abort:       Not affected

To counteract my thought though, despite it being a 16-core processor, it is 32 threads (2 threads per core), I'm guessing this is where the 32 core stuff comes from... but is that accurate? It seems to be that line in the System Info tab should only state AMD EPYC 7351P 16-Core Processor in this case.

[nebulon]

The vendor and product info comes from specific files in the /sys filesystem. Can you check those mentioned at https://git.cloudron.io/cloudron/box/-/blob/master/src/system.js?ref_type=heads#L288 on your server? Maybe OVH is not setting those correctly with your server type.

The cpu information is what we get from Nodejs os.cpu() https://nodejs.org/dist/latest-v20.x/docs/api/os.html#oscpus those are whatever the system reports, especially with modern and virtualized CPUs, those values tend to be a bit vendor specific what they deem as cpu/core/thread/... I would personally argue the lscpu output is also not what I would expect here tbh.

[girish]

To list the files, @nebulon pointed out: Vendor comes from /sys/devices/virtual/dmi/id/sys_vendor . Product name comes from /sys/devices/virtual/dmi/id/product_name

[d19dotca]

Thank you for the quick response! I checked those files and sure enough they literally contain the word “empty” rather than being physically empty, lol, so I’ll work with OVH to make sure those are set correctly I suppose. Not a big deal as it doesn’t really affect anything but just found it off it was showing as empty. Thanks so much!

For the CPU part though… that’s interesting. I wonder why it says “32 core” before the actual processor name, it’s as if it’s confusing it with threads instead of cores. But maybe it’s just the way they write it out then. Odd but I appreciate knowing where that comes from. Just conflicting value of 32-core then 16-core. lol.

[nebulon]

So in your case the 32 cores comes from the core number from the cpu info, where the rest of that line is just the processor name from the vendor which apparently contains literally "...16-Core..."

[girish]

@d19dotca said in Empty Vendor & Product, and wrong CPU info on the System Info page:

Thank you for the quick response! I checked those files and sure enough they literally contain the word “empty” rather than being physically empty, lol, so I’ll work with OVH to make sure those are set correctly I suppose

Since, it's unlikely they move quickly :-), can you check the files in /sys/devices/virtual/dmi/id/ ? Does any other file have contents which match your server?

[d19dotca]

It looks like they're all empty honestly at 4K file sizes and when I cat a couple of them they're all with the same content "empty".

ubuntu@ns574752:~$ ls -alh /sys/devices/virtual/dmi/id/
total 0
drwxr-xr-x 3 root root    0 Jan 16 17:43 .
drwxr-xr-x 3 root root    0 Jan 16 17:43 ..
-r--r--r-- 1 root root 4.0K Jan 16 17:57 bios_date
-r--r--r-- 1 root root 4.0K Jan 16 17:57 bios_release
-r--r--r-- 1 root root 4.0K Jan 16 17:43 bios_vendor
-r--r--r-- 1 root root 4.0K Jan 16 17:57 bios_version
-r--r--r-- 1 root root 4.0K Jan 16 17:57 board_asset_tag
-r--r--r-- 1 root root 4.0K Jan 16 17:43 board_name
-r-------- 1 root root 4.0K Jan 16 17:57 board_serial
-r--r--r-- 1 root root 4.0K Jan 16 17:43 board_vendor
-r--r--r-- 1 root root 4.0K Jan 16 17:57 board_version
-r--r--r-- 1 root root 4.0K Jan 16 17:43 chassis_asset_tag
-r-------- 1 root root 4.0K Jan 16 17:57 chassis_serial
-r--r--r-- 1 root root 4.0K Jan 16 17:57 chassis_type
-r--r--r-- 1 root root 4.0K Jan 16 17:57 chassis_vendor
-r--r--r-- 1 root root 4.0K Jan 16 17:57 chassis_version
-r--r--r-- 1 root root 4.0K Jan 16 17:43 modalias
drwxr-xr-x 2 root root    0 Jan 16 17:57 power
-r--r--r-- 1 root root 4.0K Jan 16 17:57 product_family
-r--r--r-- 1 root root 4.0K Jan 16 17:43 product_name
-r-------- 1 root root 4.0K Jan 16 17:43 product_serial
-r--r--r-- 1 root root 4.0K Jan 16 17:57 product_sku
-r-------- 1 root root 4.0K Jan 16 17:43 product_uuid
-r--r--r-- 1 root root 4.0K Jan 16 17:43 product_version
lrwxrwxrwx 1 root root    0 Jan 16 17:43 subsystem -> ../../../../class/dmi
-r--r--r-- 1 root root 4.0K Jan 16 17:43 sys_vendor
-rw-r--r-- 1 root root 4.0K Jan 16 17:43 uevent

ubuntu@ns574752:~$ sudo cat /sys/devices/virtual/dmi/id/product_family
empty

[nebulon]

Well then looks like OVH is not setting the DMI/SMBIOS values then properly. I guess there is not much to be done to remedy this from our side, unless some other metadata standard is used by them instead.