Bug 10362 - yocto-bsp: several config fragments yield multiple warnings when building virtual/kernel's
Summary: yocto-bsp: several config fragments yield multiple warnings when building vir...
Status: RESOLVED FIXED
Alias: None
Product: Meta-yocto
Classification: Build System, Metadata & Runtime
Component: meta-yocto (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.4 M1
Assignee: Alejandro Hernandez
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-10-03 15:54 UTC by Leonardo Sandoval Gonzalez
Modified: 2017-05-24 21:57 UTC (History)
6 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: No (bug/feature does not impact docs)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leonardo Sandoval Gonzalez 2016-10-03 15:54:55 UTC
When creating a BSP with the tool yocto-bsp and selecting SMP, the fragment smp.scc is included into KERNEL_FEATURES. However, when compiling, the following warning is shown on console:

Config: CONFIG_NR_CPUS
From:
/home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/configs/standard/a/a.cfg
/home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/configs/standard/a/standard/a/a.cfg
/home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/configs/standard/a/standard/a/cfg/smp.cfg

Requested value:  CONFIG_NR_CPUS=64
Actual value:     CONFIG_NR_CPUS=8

Config 'NR_CPUS' has the following conditionals:
  !SMP (value: "n")
MAXSMP (value: "n")
SMP && X86_BIGSMP (value: "n")
SMP && X86_32 (value: "y")
SMP (value: "y")
SMP && !MAXSMP (value: "y")
Dependency values are:
  CPUMASK_OFFSTACK [n] X86_BIGSMP [n] 512 [512] 8192 [8192] X86_64 [n] 8
[8] X86_32 [y] MAXSMP [n] 2 [2] SMP [y]

According to Bruce A. the problem comes that the corresponding fragment is applied after all fragments since KERNEL_FEATURES have always been last.
Comment 1 Bruce Ashfield 2016-10-03 15:57:04 UTC
(In reply to comment #0)
> When creating a BSP with the tool yocto-bsp and selecting SMP, the fragment
> smp.scc is included into KERNEL_FEATURES. However, when compiling, the
> following warning is shown on console:
> 
> Config: CONFIG_NR_CPUS
> From:
> /home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/
> configs/standard/a/a.cfg
> /home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/
> configs/standard/a/standard/a/a.cfg
> /home/lsandov1/poky/build/tmp/work-shared/a/kernel-source/.kernel-meta/
> configs/standard/a/standard/a/cfg/smp.cfg
> 
> Requested value:  CONFIG_NR_CPUS=64
> Actual value:     CONFIG_NR_CPUS=8
> 
> Config 'NR_CPUS' has the following conditionals:
>   !SMP (value: "n")
> MAXSMP (value: "n")
> SMP && X86_BIGSMP (value: "n")
> SMP && X86_32 (value: "y")
> SMP (value: "y")
> SMP && !MAXSMP (value: "y")
> Dependency values are:
>   CPUMASK_OFFSTACK [n] X86_BIGSMP [n] 512 [512] 8192 [8192] X86_64 [n] 8
> [8] X86_32 [y] MAXSMP [n] 2 [2] SMP [y]
> 
> According to Bruce A. the problem comes that the corresponding fragment is
> applied after all fragments since KERNEL_FEATURES have always been last.

And the fix is as I described in email, either make a kernel feature that 
turns off SMP, or in the BSP, don't add the smp kernel feature at all.
Comment 2 Leonardo Sandoval Gonzalez 2016-10-03 20:48:59 UTC
There are much more warnings on the ARM architecture that should be considered. In general a full review of the virtual/kernel templates should be done during 2.3.
Comment 3 Leonardo Sandoval Gonzalez 2016-10-03 20:51:34 UTC
Changing the title, so it is at least more general.
Comment 4 Bruce Ashfield 2016-11-03 12:48:05 UTC
I see this ended up assigned to Richard.

Unless there's a special plan for it, I can take the bug. Feel free to re-assign to me if that's the case.
Comment 5 Leonardo Sandoval Gonzalez 2017-03-24 17:01:59 UTC
The steps to reproduce this issue are not clear, so providing them this time:

1 yocto-bsp create myqemu qemu
2 chose all defaults
3 change MACHINE to myqemu and include the new layer into bblayers.conf
4 bitbake virtual/kernel

then the output mentioned on comment 1 is observed.
Comment 6 Leonardo Sandoval Gonzalez 2017-03-24 17:03:35 UTC
Alex, passing this issue to you. I think you are the right person to tackle kernel cfg issues. Let me know if you need help from me.
Comment 7 Alejandro Hernandez 2017-04-26 20:42:32 UTC
Following the same process as in bug #10425, I was able to see that our selected config values are in fact set on the merged config list, but once conf (from kconfig) is executed, the kernel disregards our values.

After diving on the kconfig code, I was able to check that indeed this is caused by a dependency issue:

Adding some debugging code to kconfig shows the following output

Validating config NR_CPUS
Current value  64 
Final value  8

In this case this is validated on the vaidate_range function from kconfig, which checks dependencies and corrects the valid range on values a certain config may be set to.

For this value the dependency that its missing is 

CONFIG_X86_BIGSMP=n

We don't set this value anywhere on kernel-meta, so we have no default value for it, but since we execute make with --allnoconfig, it ends up being set to 'n'.

According to Kconfig we have the following descriptions:

config NR_CPUS
        int "Maximum number of CPUs"
config X86_BIGSMP
        bool "Support for big SMP systems with more than 8 CPUs"

So basically we need to set CONFIG_X86_BIGSMP=y if we want NR_CPUS to be able to be > 8.

A patch to kernel-meta will be submitted to fix this.