[ 0.000000] smpboot: 32 Processors exceeds NR_CPUS limit of 16 [ 0.000000] smpboot: Allowing 16 CPUs, 0 hotplug CPUs [ 0.000000] setup_percpu: NR_CPUS:16 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:1 [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1 [ 0.000000] rcu: Offload RCU callbacks from CPUs: (none). [ 0.106139] smpboot: CPU0: AMD Ryzen 7 3700X 8-Core Processor (family: 0x17, model: 0x71, stepping: 0x0) I found that in dmesg. It looks strange to me, because it is in fact 8-core, 16-thread CPU. How 32 processors can be detected on single-socket board?
Please attach full dmesg.
Created attachment 284919 [details] dmesg.txt Full dmesg from 5.2.14
Those are only disabled local APIC IDs in the MADT table. I.e., the BIOS supports more CPUs than 16 but you have only 16 so the others are disabled. My box has 128, for example: [ 0.000000] smpboot: prefill_possible_map: possible = num_processors: 16 [ 0.000000] smpboot: prefill_possible_map: possible += disabled_cpus: 128 [ 0.000000] smpboot: 128 Processors exceeds NR_CPUS limit of 16 [ 0.000000] smpboot: Allowing 16 CPUs, 0 hotplug CPUs The disabled ones are added to the number of possible CPUs in case one can add more by hotplug. (It is not as easy as adding numbers to possible CPUs but the provision is there.) We warn there in case the user has set NR_CPUS to something lower than the actual count of CPUs present on the system so that she/he is aware at least. So, long story short, not a bug but a provision from the BIOS. You can safely ignore it. HTH.
Thank you for explanation.
I have the same issue: smpboot: 32 Processors exceeds NR_CPUS limit of 16 smpboot: Allowing 16 CPUs, 0 hotplug CPUs smpboot: CPU0: AMD Ryzen 7 3700X 8-Core Processor (family: 0x17, model: 0x71, stepping: 0x0) smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 16 CPUs smpboot: Max logical packages: 2 smpboot: Total of 16 processors activated (114982.17 BogoMIPS) I wonder if this message could be changed to indicate a firmware issue, rather than a user who's built their kernel incorrectly.
(In reply to Artem S. Tashkinov from comment #5) > I wonder if this message could be changed to indicate a firmware issue, > rather than a user who's built their kernel incorrectly. That message also reflects a case where the user might've booted with "nr_cpus=X". Otherwise, it can be safely ignored as no more cores will automagically appear than that what you already have. The distros set CONFIG_NR_CPUS high enough, default values should be high enough too. The only hypothetical problem could be if the user would set it to something lower than the cores she/he already has. But then you get what you configure so not really a problem...
(In reply to Borislav Petkov from comment #6) > (In reply to Artem S. Tashkinov from comment #5) > > I wonder if this message could be changed to indicate a firmware issue, > > rather than a user who's built their kernel incorrectly. > > That message also reflects a case where the user might've booted with > "nr_cpus=X". Otherwise, it can be safely ignored as no more cores will > automagically appear than that what you already have. > > The distros set CONFIG_NR_CPUS high enough, default values should be high > enough too. The only hypothetical problem could be if the user would set it > to something lower than the cores she/he already has. But then you get what > you configure so not really a problem... I compile my own kernel: $ grep CONFIG_NR_CPUS .config CONFIG_NR_CPUS=16 I have exactly 16 threads on my CPU. I see this message which doesn't look right. I kindly request it to be changed to reflect a BIOS/UEFI bug rather than bluntly spewing something which does not pertain to the reality of my HW configuration. I don't think it's too difficult to fix. Thank you!
(In reply to Artem S. Tashkinov from comment #7) > I kindly request it to be changed to reflect a BIOS/UEFI bug rather than > bluntly spewing something which does not pertain to the reality of my HW > configuration. I don't think it's too difficult to fix. I don't think my previous comment meant anything. So, if you really want to "fix" whatever it is you feel is broken, send patches.
(In reply to Borislav Petkov from comment #8) > I don't think my previous comment meant anything. So, if you really want to > "fix" whatever it is you feel is broken, send patches. I'm terribly sorry for my comments - I hadn't read comment 3 before adding them. I feel totally ashamed. Again, my apologies - there's no bug but the wording could be changed to explain the situation clearly, e.g. Instead of saying: smpboot: 32 Processors exceeds NR_CPUS limit of 16 You could say something like: smpboot: Motherboard supports up to 32 logical CPUs while your kernel configuration has a limit of 16 (NR_CPUS )