Debian only sees one CPU core on a 2 core 4 thread machine

Hello,

I have a i5-3470T thin-client that should show 4 CPUs (2 cores 4 threads based on ARK). However it is only showing one. I use it headless to run docker with various home automation containers and it has been running OK, but I would like to push it further and would like it to use all of the CPU. I read on this and other forums that there is a BIOS option that may need checking, but when I looked I could not find it.

I would greatly appreciate any help/pointers in solving this.

Below is the nofetch and lscpu output for some system info.

       _,met$$$$$gg.          vav@brick 
    ,g$$$$$$$$$$$$$$$P.       --------- 
  ,g$$P"     """Y$$.".        OS: Debian GNU/Linux trixie/sid x86_64 
 ,$$P'              `$$$.     Host: 3237D46 ThinkCentre M92P 
',$$P       ,ggs.     `$$b:   Kernel: 6.5.0-5-amd64 
`d$$'     ,$P"'   .    $$$    Uptime: 3 days, 22 hours, 9 mins 
 $$P      d$'     ,    $$P    Packages: 1495 (dpkg), 6 (flatpak) 
 $$:      $$.   -    ,d$$'    Shell: bash 5.2.21 
 $$;      Y$b._   _,d$P'      Terminal: /dev/pts/0 
 Y$$.    `.`"Y$$$$P"'         CPU: Intel i5-3470T (1) @ 2.900GHz 
 `$$b      "-.__              GPU: Intel HD Graphics 
  `Y$$                        Memory: 1655MiB / 7747MiB 
   `Y$$.
     `$$b.                                            
       `Y$$b.                                         
          `"Y$b._
              `"""

Architecture:           x86_64
  CPU op-mode(s):       32-bit, 64-bit
  Address sizes:        36 bits physical, 48 bits virtual
  Byte Order:           Little Endian
CPU(s):                 1
  On-line CPU(s) list:  0
Vendor ID:              GenuineIntel
  Model name:           Intel(R) Core(TM) i5-3470T CPU @ 2.90GHz
    CPU family:         6
    Model:              58
    Thread(s) per core: 1
    Core(s) per socket: 1
    Socket(s):          1
    Stepping:           9
    CPU(s) scaling MHz: 84%
    CPU max MHz:        2900.0000
    CPU min MHz:        1600.0000
    BogoMIPS:           5787.01
    Flags:              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
                         cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
                         tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon p
                        ebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfm
                        perf pni pclmulqdq dtes64 monitor ds_cpl smx est tm2 sss
                        e3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_d
                        eadline_timer aes xsave avx f16c rdrand lahf_lm cpuid_fa
                        ult epb pti fsgsbase smep erms xsaveopt dtherm arat pln 
                        pts
Caches (sum of all):    
  L1d:                  32 KiB (1 instance)
  L1i:                  32 KiB (1 instance)
  L2:                   256 KiB (1 instance)
  L3:                   3 MiB (1 instance)
NUMA:                   
  NUMA node(s):         1
  NUMA node0 CPU(s):    0
Vulnerabilities:        
  Gather data sampling: Not affected
  Itlb multihit:        KVM: Mitigation: VMX unsupported
  L1tf:                 Mitigation; PTE Inversion
  Mds:                  Vulnerable: Clear CPU buffers attempted, no microcode; S
                        MT disabled
  Meltdown:             Mitigation; PTI
  Mmio stale data:      Unknown: No mitigations
  Retbleed:             Not affected
  Spec rstack overflow: Not affected
  Spec store bypass:    Vulnerable
  Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer 
                        sanitization
  Spectre v2:           Mitigation; Retpolines, STIBP disabled, RSB filling, PBR
                        SB-eIBRS Not affected
  Srbds:                Vulnerable: No microcode
  Tsx async abort:      Not affected

If this isn't running inside a VM/hypervisor that is restricted to 1 vcpu, it very likely is a BIOS option - it will probably be called something like 'Active Processor Cores' or 'Processor Threads' or something, and I would not be surprised if its hidden 3 submenus down in a very non-intuitive place (I've only ever seen that setting be 'easy' to find on Xeon and Opteron workstations). That will maybe only be half of the equation though - that setting likely only takes a value of 1 or 2, there will also probably be another option called 'HyperThreading Enable' or something of that sort, which gets you the SMT feature and the 'extra' logical processors. I will also not be surprised if these two settings are not in the same submenu.

4 threads showing here:

# pinxi -SGz
System:
  Kernel: 6.5.0-4-amd64 arch: x86_64 bits: 64
  Console: pty pts/0 Distro: Debian GNU/Linux trixie/sid
Graphics:
  Device-1: Intel 4th Generation Core Processor Family Integrated Graphics
    driver: i915 v: kernel
  Display: server: X.org v: 1.21.1.9 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: crocus gpu: i915 resolution: 1: 1680x1050
    2: 1920x1200 3: 1680x1050
# pinxi -Caz
CPU:
  Info: model: Intel Core i3-4150T socket: BGA1155 bits: 64 type: MT MCP
    arch: Haswell gen: core 4 level: v3 note: check built: 2013-15
    process: Intel 22nm family: 6 model-id: 0x3C (60) stepping: 3
    microcode: 0x19
  Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache:
    L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB
    L3: 3 MiB desc: 1x3 MiB
  Speed (MHz): avg: 2450 high: 3000 min/max: 800/3000 base/boost: 3000/3800
    scaling: driver: intel_cpufreq governor: schedutil volts: 1.2 V
    ext-clock: 100 MHz cores: 1: 3000 2: 3000 3: 3000 4: 800 bogomips: 23998
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: vulnerable
  Type: mds status: Vulnerable; SMT vulnerable
  Type: meltdown status: Vulnerable
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 status: Vulnerable: __user pointer sanitization and
    usercopy barriers only; no swapgs barriers
  Type: spectre_v2 status: Vulnerable, STIBP: disabled, PBRSB-eIBRS: Not
    affected
  Type: srbds status: Vulnerable: No microcode
  Type: tsx_async_abort status: Not affected
#

If you can't find anything in BIOS or anywhere else you can think of, check for a BIOS update. It's commonly suggested to do a BIOS reset when doing a BIOS update. You might just try that. If you can't find the official way to do it, it can be done by removing the CMOS battery and power supply cable. A short period, less than a few minutes, is supposedly enough, but it could take several hours if the chip resists the passive reset.