tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
branch HEAD: 3387ce4d8a5f2956fab827edf499fe6780e83faa headers/prep: Fix header to build standalone: <linux/psi.h>
elapsed time: 730m
configs tested: 114
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20220321
arm cm_x300_defconfig
sh sh03_defconfig
mips maltasmvp_defconfig
sh sh7763rdp_defconfig
arm h3600_defconfig
arm aspeed_g5_defconfig
sh rts7751r2d1_defconfig
sh edosk7760_defconfig
arc nsimosci_defconfig
sh rsk7201_defconfig
h8300 edosk2674_defconfig
arc nsimosci_hs_smp_defconfig
sh microdev_defconfig
sh ul2_defconfig
um defconfig
xtensa xip_kc705_defconfig
arc hsdk_defconfig
um alldefconfig
mips vocore2_defconfig
arm randconfig-c002-20220321
arm randconfig-c002-20220320
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allyesconfig
m68k allmodconfig
nds32 allnoconfig
nios2 defconfig
arc allyesconfig
csky defconfig
alpha defconfig
nds32 defconfig
alpha allyesconfig
nios2 allyesconfig
arc defconfig
sh allmodconfig
h8300 allyesconfig
xtensa allyesconfig
parisc defconfig
parisc64 defconfig
s390 allmodconfig
parisc allyesconfig
s390 allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
i386 debian-10.3-kselftests
i386 debian-10.3
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a013-20220321
x86_64 randconfig-a012-20220321
x86_64 randconfig-a014-20220321
x86_64 randconfig-a011-20220321
x86_64 randconfig-a016-20220321
x86_64 randconfig-a015-20220321
i386 randconfig-a013-20220321
i386 randconfig-a011-20220321
i386 randconfig-a012-20220321
i386 randconfig-a014-20220321
i386 randconfig-a016-20220321
i386 randconfig-a015-20220321
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um i386_defconfig
um x86_64_defconfig
x86_64 defconfig
x86_64 allyesconfig
x86_64 kexec
x86_64 rhel-8.3
x86_64 rhel-8.3-func
x86_64 rhel-8.3-kunit
clang tested configs:
arm moxart_defconfig
mips bmips_stb_defconfig
powerpc allmodconfig
mips tb0287_defconfig
powerpc mpc832x_rdb_defconfig
mips cu1000-neo_defconfig
powerpc mpc512x_defconfig
arm cns3420vb_defconfig
riscv rv32_defconfig
x86_64 randconfig-a001-20220321
x86_64 randconfig-a003-20220321
x86_64 randconfig-a005-20220321
x86_64 randconfig-a004-20220321
x86_64 randconfig-a002-20220321
x86_64 randconfig-a006-20220321
i386 randconfig-a001-20220321
i386 randconfig-a006-20220321
i386 randconfig-a003-20220321
i386 randconfig-a005-20220321
i386 randconfig-a004-20220321
i386 randconfig-a002-20220321
riscv randconfig-r042-20220320
hexagon randconfig-r045-20220321
hexagon randconfig-r045-20220320
hexagon randconfig-r041-20220321
hexagon randconfig-r041-20220320
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Hello,
On Tue, Mar 22, 2022 at 06:36:16AM +0800, kernel test robot wrote:
> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> branch HEAD: 3387ce4d8a5f2956fab827edf499fe6780e83faa headers/prep: Fix header to build standalone: <linux/psi.h>
>
> elapsed time: 730m
>
> configs tested: 114
> configs skipped: 3
>
> The following configs have been built successfully.
> More configs may be tested in the coming days.
>
> gcc tested configs:
...
> arm allyesconfig
> arm allmodconfig
This caught my eye due to my earlier report:
https://lore.kernel.org/r/[email protected]/
Are you sure these configurations built sucessfully?
$ git show -s
commit 3387ce4d8a5f2956fab827edf499fe6780e83faa
Author: Ingo Molnar <[email protected]>
Date: Mon Mar 21 11:05:50 2022 +0100
headers/prep: Fix header to build standalone: <linux/psi.h>
Add the <linux/cgroup-defs.h> dependency to <linux/psi.h>, because
cgroup_move_task() will dereference 'struct css_set'.
( Only older toolchains are affected, due to variations in
the implementation of rcu_assign_pointer() et al. )
Cc: Peter Zijlstra <[email protected]>
Cc: Linus Torvalds <[email protected]>
Reported-by: Sachin Sant <[email protected]>
Reported-by: Andrew Morton <[email protected]>
Reported-by: Borislav Petkov <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig kernel/sched/
In file included from kernel/sched/fair.c:52:
kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
87 | # include <asm/paravirt_api_clock.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.build:288: kernel/sched/fair.o] Error 1
In file included from kernel/sched/build_utility.c:52:
kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
87 | # include <asm/paravirt_api_clock.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.build:288: kernel/sched/build_utility.o] Error 1
In file included from kernel/sched/build_policy.c:33:
kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
87 | # include <asm/paravirt_api_clock.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.build:288: kernel/sched/build_policy.o] Error 1
In file included from kernel/sched/core.c:81:
kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
87 | # include <asm/paravirt_api_clock.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
...
I am curious to know how this error was not caught by these builds?
Perhaps an old .config from a previous allmodconfig is being reused,
rather than just running "make allmodconfig"? If that is the case, it
seems like that methodology will miss out on new configuration options
over time.
Cheers,
Nathan
On 3/22/2022 7:17 AM, Nathan Chancellor wrote:
> Hello,
>
> On Tue, Mar 22, 2022 at 06:36:16AM +0800, kernel test robot wrote:
>> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
>> branch HEAD: 3387ce4d8a5f2956fab827edf499fe6780e83faa headers/prep: Fix header to build standalone: <linux/psi.h>
>>
>> elapsed time: 730m
>>
>> configs tested: 114
>> configs skipped: 3
>>
>> The following configs have been built successfully.
>> More configs may be tested in the coming days.
>>
>> gcc tested configs:
> ...
>> arm allyesconfig
>> arm allmodconfig
>
> This caught my eye due to my earlier report:
>
> https://lore.kernel.org/r/[email protected]/
>
> Are you sure these configurations built sucessfully?
>
>
> $ git show -s
> commit 3387ce4d8a5f2956fab827edf499fe6780e83faa
> Author: Ingo Molnar <[email protected]>
> Date: Mon Mar 21 11:05:50 2022 +0100
>
> headers/prep: Fix header to build standalone: <linux/psi.h>
>
> Add the <linux/cgroup-defs.h> dependency to <linux/psi.h>, because
> cgroup_move_task() will dereference 'struct css_set'.
>
> ( Only older toolchains are affected, due to variations in
> the implementation of rcu_assign_pointer() et al. )
>
> Cc: Peter Zijlstra <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Reported-by: Sachin Sant <[email protected]>
> Reported-by: Andrew Morton <[email protected]>
> Reported-by: Borislav Petkov <[email protected]>
> Signed-off-by: Ingo Molnar <[email protected]>
>
> $ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig kernel/sched/
> In file included from kernel/sched/fair.c:52:
> kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
> 87 | # include <asm/paravirt_api_clock.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[3]: *** [scripts/Makefile.build:288: kernel/sched/fair.o] Error 1
> In file included from kernel/sched/build_utility.c:52:
> kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
> 87 | # include <asm/paravirt_api_clock.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[3]: *** [scripts/Makefile.build:288: kernel/sched/build_utility.o] Error 1
> In file included from kernel/sched/build_policy.c:33:
> kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
> 87 | # include <asm/paravirt_api_clock.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> make[3]: *** [scripts/Makefile.build:288: kernel/sched/build_policy.o] Error 1
> In file included from kernel/sched/core.c:81:
> kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h: No such file or directory
> 87 | # include <asm/paravirt_api_clock.h>
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> ...
>
> I am curious to know how this error was not caught by these builds?
> Perhaps an old .config from a previous allmodconfig is being reused,
> rather than just running "make allmodconfig"? If that is the case, it
> seems like that methodology will miss out on new configuration options
> over time.
>
> Cheers,
> Nathan
>
Hi Nathan,
Thanks for your reminding, the problem commit is 4ff8f2ca6ccd
("sched/headers: Reorganize, clean up and optimize kernel/sched/sched.h
dependencies"),
the bot has sent two build reports related to it:
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
and more reports were stopped to avoid too many noise, like below one:
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: 97add482e9033a9386baa8824fbea34d0cbfe663
commit: 4ff8f2ca6ccd9e0cc5665d09f86d631b3ae3a14c [7191/13392]
sched/headers: Reorganize, clean up and optimize kernel/sched/sched.h
dependencies
:::::: branch date: 17 hours ago
:::::: commit date: 3 weeks ago
config: arm-randconfig-c002-20220317 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ff8f2ca6ccd9e0cc5665d09f86d631b3ae3a14c
git remote add linux-next
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git fetch --no-tags linux-next master
git checkout 4ff8f2ca6ccd9e0cc5665d09f86d631b3ae3a14c
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0
make.cross O=build_dir ARCH=arm SHELL=/bin/bash kernel/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
In file included from kernel/sched/core.c:79:
>> kernel/sched/sched.h:87:11: fatal error: asm/paravirt_api_clock.h:
No such file or directory
87 | # include <asm/paravirt_api_clock.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
We'll adjust the strategy avoid blocking some important reports.
Best Regards,
Rong Chen
On Tue, Mar 22, 2022 at 10:39:41AM +0800, Chen, Rong A wrote:
> On 3/22/2022 7:17 AM, Nathan Chancellor wrote:
> > Hello,
> >
> > On Tue, Mar 22, 2022 at 06:36:16AM +0800, kernel test robot wrote:
> > > tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
> > > branch HEAD: 3387ce4d8a5f2956fab827edf499fe6780e83faa headers/prep: Fix header to build standalone: <linux/psi.h>
> > >
> > > elapsed time: 730m
> > >
> > > configs tested: 114
> > > configs skipped: 3
> > >
> > > The following configs have been built successfully.
> > > More configs may be tested in the coming days.
> > >
> > > gcc tested configs:
> > ...
> > > arm allyesconfig
> > > arm allmodconfig
> >
> > Are you sure these configurations built sucessfully?
...
> Thanks for your reminding, the problem commit is 4ff8f2ca6ccd
> ("sched/headers: Reorganize, clean up and optimize kernel/sched/sched.h
> dependencies"),
> the bot has sent two build reports related to it:
>
> https://lore.kernel.org/all/[email protected]/
> https://lore.kernel.org/all/[email protected]/
>
> and more reports were stopped to avoid too many noise, like below one:
...
> We'll adjust the strategy avoid blocking some important reports.
Oh *PLEASE* never report a branch as building if there's errors.
It could be I (force) push a branch multiple times before I get any
0day reports back (0day has gotten *soooo* slow) so I only ever look at
the latest report -- possibly days later.
If you then falsly report the branch as being good, because you're
suppressing errors, things *will* go bad.
On 3/25/2022 1:58 AM, Peter Zijlstra wrote:
> On Tue, Mar 22, 2022 at 10:39:41AM +0800, Chen, Rong A wrote:
>> On 3/22/2022 7:17 AM, Nathan Chancellor wrote:
>>> Hello,
>>>
>>> On Tue, Mar 22, 2022 at 06:36:16AM +0800, kernel test robot wrote:
>>>> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
>>>> branch HEAD: 3387ce4d8a5f2956fab827edf499fe6780e83faa headers/prep: Fix header to build standalone: <linux/psi.h>
>>>>
>>>> elapsed time: 730m
>>>>
>>>> configs tested: 114
>>>> configs skipped: 3
>>>>
>>>> The following configs have been built successfully.
>>>> More configs may be tested in the coming days.
>>>>
>>>> gcc tested configs:
>>> ...
>>>> arm allyesconfig
>>>> arm allmodconfig
>>>
>
>>> Are you sure these configurations built sucessfully?
>
> ...
>
>> Thanks for your reminding, the problem commit is 4ff8f2ca6ccd
>> ("sched/headers: Reorganize, clean up and optimize kernel/sched/sched.h
>> dependencies"),
>> the bot has sent two build reports related to it:
>>
>> https://lore.kernel.org/all/[email protected]/
>> https://lore.kernel.org/all/[email protected]/
>>
>> and more reports were stopped to avoid too many noise, like below one:
>
> ...
>
>> We'll adjust the strategy avoid blocking some important reports.
>
> Oh *PLEASE* never report a branch as building if there's errors.
> It could be I (force) push a branch multiple times before I get any
> 0day reports back (0day has gotten *soooo* slow) so I only ever look at
> the latest report -- possibly days later.
Hi Peter,
Sorry for the bad experience, I'm not sure the meaning of "a branch as
building", is there a way to know the branch is not ready, or we can
postpone the test for a branch by a day?
>
> If you then falsly report the branch as being good, because you're
> suppressing errors, things *will* go bad.
>
>
yes, current the summary report only shows the errors that bisected
successfully in a cycle, but it may causes some errors missing
and old errors still in the report, we plan to redesign the report
to present all (may a lot) recent errors.
Best Regards,
Rong Chen
On 3/25/2022 7:54 PM, Peter Zijlstra wrote:
> On Fri, Mar 25, 2022 at 06:45:24PM +0800, Chen, Rong A wrote:
>
>>> Oh *PLEASE* never report a branch as building if there's errors.
>>> It could be I (force) push a branch multiple times before I get any
>>> 0day reports back (0day has gotten *soooo* slow) so I only ever look at
>>> the latest report -- possibly days later.
>>
>> Hi Peter,
>>
>> Sorry for the bad experience, I'm not sure the meaning of "a branch as
>> building", is there a way to know the branch is not ready, or we can
>> postpone the test for a branch by a day?
>
> I was just commenting in general; never send a mail with "SUCCESS" in
> the subject (as per this thread) when there are errors/warns with it,
> supressed or otherwise.
>
> If you do want to supress warnings (I'm not sure why; a few more emails
> in my inbox really aren't going to make a difference) then please state
> so explicitly with a link to the email with the report.
>
> The thing I worry about is that I often wait for a SUCCESS mail from
> 0day robot before I push code to tip. If the SUCCESS is unreliable, this
> is not good.
>
Hi Peter,
Thanks for your advice, we will fix the problem in the near future.
Best Regards,
Rong Chen
On Fri, Mar 25, 2022 at 06:45:24PM +0800, Chen, Rong A wrote:
> > Oh *PLEASE* never report a branch as building if there's errors.
> > It could be I (force) push a branch multiple times before I get any
> > 0day reports back (0day has gotten *soooo* slow) so I only ever look at
> > the latest report -- possibly days later.
>
> Hi Peter,
>
> Sorry for the bad experience, I'm not sure the meaning of "a branch as
> building", is there a way to know the branch is not ready, or we can
> postpone the test for a branch by a day?
I was just commenting in general; never send a mail with "SUCCESS" in
the subject (as per this thread) when there are errors/warns with it,
supressed or otherwise.
If you do want to supress warnings (I'm not sure why; a few more emails
in my inbox really aren't going to make a difference) then please state
so explicitly with a link to the email with the report.
The thing I worry about is that I often wait for a SUCCESS mail from
0day robot before I push code to tip. If the SUCCESS is unreliable, this
is not good.