10362 2016-10-03 15:54:55 +0000 yocto-bsp: several config fragments yield multiple warnings when building virtual/kernel's 2017-05-24 21:57:17 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto 2.2 x86 Multiple RESOLVED FIXED Medium+ normal 2.4 M1 1 leonardo.sandoval.gonzalez alejandro.hernandez bruce.ashfield juan.m.cruz.alcaraz poky.bs.watcher poky.watcher richard.purdie sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 66807 0 leonardo.sandoval.gonzalez 2016-10-03 15:54:55 +0000 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. 66808 1 bruce.ashfield 2016-10-03 15:57:04 +0000 (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. 66839 2 leonardo.sandoval.gonzalez 2016-10-03 20:48:59 +0000 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. 66840 3 leonardo.sandoval.gonzalez 2016-10-03 20:51:34 +0000 Changing the title, so it is at least more general. 67890 4 bruce.ashfield 2016-11-03 12:48:05 +0000 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. 71712 5 leonardo.sandoval.gonzalez 2017-03-24 17:01:59 +0000 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. 71714 6 leonardo.sandoval.gonzalez 2017-03-24 17:03:35 +0000 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. 72875 7 alejandro.hernandez 2017-04-26 20:42:32 +0000 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. 73487 8 alejandro.hernandez 2017-05-24 21:57:17 +0000 Fixed: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/commit/?h=yocto-4.9&id=5fd0435f4d40c03bc5a06389d22dbafd5086e7ab