On 26.09.2023 21:49, Andrew Cooper wrote: > On 25/09/2023 11:42 pm, Shawn Anastasio wrote: >> Since ppc64le is still undergoing early bringup, disable the randconfig >> CI build which was causing spurious CI failures. >> >> Signed-off-by: Shawn Anastasio <[email protected]> >> Reported-by: Jan Beulich <[email protected]> >> --- >> automation/gitlab-ci/build.yaml | 18 ------------------ >> 1 file changed, 18 deletions(-) >> >> diff --git a/automation/gitlab-ci/build.yaml >> b/automation/gitlab-ci/build.yaml >> index 1619e9a558..32af30cced 100644 >> --- a/automation/gitlab-ci/build.yaml >> +++ b/automation/gitlab-ci/build.yaml >> @@ -563,24 +563,6 @@ debian-bullseye-gcc-ppc64le-debug: >> KBUILD_DEFCONFIG: ppc64_defconfig >> HYPERVISOR_ONLY: y >> >> -debian-bullseye-gcc-ppc64le-randconfig: >> - extends: .gcc-ppc64le-cross-build >> - variables: >> - CONTAINER: debian:bullseye-ppc64le >> - KBUILD_DEFCONFIG: ppc64_defconfig >> - RANDCONFIG: y >> - EXTRA_FIXED_RANDCONFIG: >> - CONFIG_COVERAGE=n >> - >> -debian-bullseye-gcc-ppc64le-debug-randconfig: >> - extends: .gcc-ppc64le-cross-build-debug >> - variables: >> - CONTAINER: debian:bullseye-ppc64le >> - KBUILD_DEFCONFIG: ppc64_defconfig >> - RANDCONFIG: y >> - EXTRA_FIXED_RANDCONFIG: >> - CONFIG_COVERAGE=n > > I know this has been committed, but it shouldn't have been. Randconfig > is important to have even at this point in the bringup.
Well. As so often you only comment when it's too late. The question whether randconfig is sensible to have in the bringup phase was raised earlier. You could have said "yes, keep it" there. With there not having been any comment on the suggestion to drop this (and I similarly think for RISC-V, which is likely to be similarly affected the moment the full build is enabled there), I didn't expect any opposition to the patch, and hence went ahead committing it. > For options which are known-incompatible, append them to > EXTRA_FIXED_RANDCONFIG, just like COVERAGE already is. But in this early phase that merely means re-stating some/all of what the default config states (which may in fact state a few too many fixed settings). > However, it was only grant tables which showed up as broken, and ought > to be easy to address. It may only be grant tables right now (that's what CI had spotted), but other settings are likely to become (transient) problems as well. See e.g. #define smp_processor_id() 0 /* TODO: Fix this */ which imo might lead to the compiler spot bogus constructs, just because at the same time NR_CPUS > 1. Jan
