tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type checks
date: 5 months ago
config: arc-randconfig-r004-20200824 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.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
git checkout de8f5e4f2dc1f032b46afda0a78cab5456974f89
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
On 2020-08-24 10:17:19 [+0800], kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type checks
> date: 5 months ago
> config: arc-randconfig-r004-20200824 (attached as .config)
> compiler: arc-elf-gcc (GCC) 9.3.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
> git checkout de8f5e4f2dc1f032b46afda0a78cab5456974f89
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <[email protected]>
>
> All errors (new ones prefixed by >>):
>
> {standard input}: Assembler messages:
> >> {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
>
I have here gcc 10 and the output is:
| CC arch/arc/kernel/signal.o
|arch/arc/include/asm/bitops.h: Assembler messages:
|arch/arc/include/asm/bitops.h:236: Error: junk at end of line, first unrecognized character is `0'
|arch/arc/include/asm/bitops.h:236: Error: junk at end of line, first unrecognized character is `0'
|make[3]: *** [scripts/Makefile.build:283: arch/arc/kernel/signal.o] Error 1
|make[2]: *** [scripts/Makefile.build:500: arch/arc/kernel] Error 2
|make[1]: *** [Makefile:1788: arch/arc] Error 2
the reason is that:
| #ifndef CONFIG_ARC_PLAT_EZNPS
| BIT_OPS(set, |, bset)
| BIT_OPS(clear, & ~, bclr)
| BIT_OPS(change, ^, bxor)
| #else
| BIT_OPS(set, |, CTOP_INST_AOR_DI_R2_R2_R3)
| BIT_OPS(clear, & ~, CTOP_INST_AAND_DI_R2_R2_R3)
| BIT_OPS(change, ^, CTOP_INST_AXOR_DI_R2_R2_R3)
| #endif
and the config supplied does not accept CTOP_INST_AAND_DI_R2_R2_R3
(which is
#define CTOP_INST_AAND_DI_R2_R2_R3 0x4A664C04
)
and the assembler does not like that.
After the removal CONFIG_ARC_PLAT_EZNPS I got to stage 2:
|drivers/irqchip/irq-eznps.c:80:16: error: 'CTOP_AUX_IACK' undeclared (first use in this function)
| 80 | write_aux_reg(CTOP_AUX_IACK, 1 << irq);
so I removed CONFIG_EZNPS_GIC. And then I ended with:
| LD vmlinux.o
|arc-linux-ld: gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o): compiled for a little endian system and target is big endian
|arc-linux-ld: failed to merge target specific data of file gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o)
Please update CI and ARC.
Sebastian
+CC Ofer
On 8/24/20 2:58 AM, Sebastian Andrzej Siewior wrote:
> On 2020-08-24 10:17:19 [+0800], kernel test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
>> commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type checks
>> date: 5 months ago
>> config: arc-randconfig-r004-20200824 (attached as .config)
>> compiler: arc-elf-gcc (GCC) 9.3.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
>> git checkout de8f5e4f2dc1f032b46afda0a78cab5456974f89
>> # save the attached .config to linux build tree
>> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
>>
>> If you fix the issue, kindly add following tag as appropriate
>> Reported-by: kernel test robot <[email protected]>
>>
>> All errors (new ones prefixed by >>):
>>
>> {standard input}: Assembler messages:
>>>> {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
>>
The error above was fixed back in April:
799587d5731db9dc ("ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT")
> I have here gcc 10 and the output is:
I suppose this is mainline gcc 10 ? Although it doesn't seem like compiler version
related.
> | CC arch/arc/kernel/signal.o
> |arch/arc/include/asm/bitops.h: Assembler messages:
> |arch/arc/include/asm/bitops.h:236: Error: junk at end of line, first unrecognized character is `0'
> |arch/arc/include/asm/bitops.h:236: Error: junk at end of line, first unrecognized character is `0'
> |make[3]: *** [scripts/Makefile.build:283: arch/arc/kernel/signal.o] Error 1
> |make[2]: *** [scripts/Makefile.build:500: arch/arc/kernel] Error 2
> |make[1]: *** [Makefile:1788: arch/arc] Error 2
>
> the reason is that:
> | #ifndef CONFIG_ARC_PLAT_EZNPS
> | BIT_OPS(set, |, bset)
> | BIT_OPS(clear, & ~, bclr)
> | BIT_OPS(change, ^, bxor)
> | #else
> | BIT_OPS(set, |, CTOP_INST_AOR_DI_R2_R2_R3)
> | BIT_OPS(clear, & ~, CTOP_INST_AAND_DI_R2_R2_R3)
> | BIT_OPS(change, ^, CTOP_INST_AXOR_DI_R2_R2_R3)
> | #endif
>
> and the config supplied does not accept CTOP_INST_AAND_DI_R2_R2_R3
> (which is
> #define CTOP_INST_AAND_DI_R2_R2_R3 0x4A664C04
> )
> and the assembler does not like that.
> After the removal CONFIG_ARC_PLAT_EZNPS I got to stage 2:
> |drivers/irqchip/irq-eznps.c:80:16: error: 'CTOP_AUX_IACK' undeclared (first use in this function)
> | 80 | write_aux_reg(CTOP_AUX_IACK, 1 << irq);
>
Indeed this is a problem I can reproduce. Enabling CONFIG_EZNPS_GIC on a non
ARC700 build causes the issue: the ctop header is inside platform code
(arch/arc/plat-eznps/include/plat/ctop.h) which obviously fails if not building
for ARC.
My solution is to move ctop.h to include/soc/nps/plat/.
> so I removed CONFIG_EZNPS_GIC. And then I ended with:
> | LD vmlinux.o
> |arc-linux-ld: gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o): compiled for a little endian system and target is big endian
> |arc-linux-ld: failed to merge target specific data of file gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o)
This is unrelated since original .config with CONFIG_ARC_PLAT_EZNPS would have
selected Big endina build, but you need a BE toolchain to get that working (since
libgcc emulation code still comes from toolchain).
>
> Please update CI and ARC.
Nothing to update in CI. I'll send the ARC patch as a follow up.
>
> Sebastian
>
Thx for reporting.
-Vineet
On 8/24/20 11:21 AM, Vineet Gupta wrote:
>> and the assembler does not like that.
>> After the removal CONFIG_ARC_PLAT_EZNPS I got to stage 2:
>> |drivers/irqchip/irq-eznps.c:80:16: error: 'CTOP_AUX_IACK' undeclared (first use in this function)
>> | 80 | write_aux_reg(CTOP_AUX_IACK, 1 << irq);
>>
> Indeed this is a problem I can reproduce. Enabling CONFIG_EZNPS_GIC on a non
> ARC700 build causes the issue: the ctop header is inside platform code
> (arch/arc/plat-eznps/include/plat/ctop.h) which obviously fails if not building
> for ARC.
>
> My solution is to move ctop.h to include/soc/nps/plat/.
This is turning out to be rat's nest. That header when moved causes other issues.
I don't have time to clean up all the mess so I'll just fix it up by doing the
minimal change.
-Vineet
On 2020-08-24 18:21:21 [+0000], Vineet Gupta wrote:
> >>>> {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
> >>
>
> The error above was fixed back in April:
> 799587d5731db9dc ("ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT")
This commit is
|git describe --contains 799587d5731db9dc
|v5.7-rc7~32^2~2
and CI said:
|head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
^^ v5.9-rc2
|commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type checks
^^ v5.7-rc1
so my assumption was that it tested rc2 and bisected it down to that
commit. Otherwise I don't see the point in testing such an old commit on
a recent -rc2 and complaining about things not related to one another.
> > I have here gcc 10 and the output is:
>
> I suppose this is mainline gcc 10 ? Although it doesn't seem like compiler version
> related.
Sorry for that. It is
|$ ~/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc -v
|Using built-in specs.
|COLLECT_GCC=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc
|COLLECT_LTO_WRAPPER=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/../libexec/gcc/arc-linux/10.1.0/lto-wrapper
|Target: arc-linux
|Configured with: /home/arnd/git/gcc/configure --target=arc-linux --enable-targets=all --prefix=/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/arc-linux --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
|Thread model: single
|Supported LTO compression algorithms: zlib
|gcc version 10.1.0 (GCC)
This is the one built by Arnd and hosted at
https://www.kernel.org/pub/tools/crosstool/
Is it suitable for testing?
> > and the assembler does not like that.
> > After the removal CONFIG_ARC_PLAT_EZNPS I got to stage 2:
> > |drivers/irqchip/irq-eznps.c:80:16: error: 'CTOP_AUX_IACK' undeclared (first use in this function)
> > | 80 | write_aux_reg(CTOP_AUX_IACK, 1 << irq);
> >
>
> Indeed this is a problem I can reproduce. Enabling CONFIG_EZNPS_GIC on a non
> ARC700 build causes the issue: the ctop header is inside platform code
> (arch/arc/plat-eznps/include/plat/ctop.h) which obviously fails if not building
> for ARC.
>
> My solution is to move ctop.h to include/soc/nps/plat/.
You know probably best :)
> > so I removed CONFIG_EZNPS_GIC. And then I ended with:
> > | LD vmlinux.o
> > |arc-linux-ld: gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o): compiled for a little endian system and target is big endian
> > |arc-linux-ld: failed to merge target specific data of file gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o)
>
> This is unrelated since original .config with CONFIG_ARC_PLAT_EZNPS would have
> selected Big endina build, but you need a BE toolchain to get that working (since
> libgcc emulation code still comes from toolchain).
Is a switch missing while building the gcc, another gcc target needed or
is this something that is not part of upstream gcc?
> >
> > Please update CI and ARC.
>
> Nothing to update in CI. I'll send the ARC patch as a follow up.
but it shouldn't complain about a commit merged in v5.7-rc1 because it
caused an error which was then fixed in v5.7-rc7 while using HEAD
v5.9-rc2?
> Thx for reporting.
You are welcome.
> -Vineet
Sebastian
Hi Sebastian,
On 8/24/20 12:35 PM, Sebastian Andrzej Siewior wrote:
> On 2020-08-24 18:21:21 [+0000], Vineet Gupta wrote:
>>>>>> {standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
>>>>
>>
>> The error above was fixed back in April:
>> 799587d5731db9dc ("ARC: [plat-eznps]: Restrict to CONFIG_ISA_ARCOMPACT")
>
> This commit is
> |git describe --contains 799587d5731db9dc
> |v5.7-rc7~32^2~2
>
> and CI said:
> |head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
> ^^ v5.9-rc2
> |commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type checks
> ^^ v5.7-rc1
>
> so my assumption was that it tested rc2 and bisected it down to that
> commit. Otherwise I don't see the point in testing such an old commit on
> a recent -rc2 and complaining about things not related to one another.
/me confused and a bit out of context here. I didn't see the original CI report
but anyways, we know the code issue... read below
>
>>> I have here gcc 10 and the output is:
>>
>> I suppose this is mainline gcc 10 ? Although it doesn't seem like compiler version
>> related.
>
> Sorry for that. It is
> |$ ~/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc -v
> |Using built-in specs.
> |COLLECT_GCC=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/arc-linux-gcc
> |COLLECT_LTO_WRAPPER=/home/bigeasy/cross-gcc/gcc-10.1.0-nolibc/arc-linux/bin/../libexec/gcc/arc-linux/10.1.0/lto-wrapper
> |Target: arc-linux
> |Configured with: /home/arnd/git/gcc/configure --target=arc-linux --enable-targets=all --prefix=/home/arnd/cross/x86_64/gcc-10.1.0-nolibc/arc-linux --enable-languages=c --without-headers --disable-bootstrap --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --disable-libquadmath --disable-libatomic --disable-libcc1 --disable-libmpx --enable-checking=release
> |Thread model: single
> |Supported LTO compression algorithms: zlib
> |gcc version 10.1.0 (GCC)
>
> This is the one built by Arnd and hosted at
> https://www.kernel.org/pub/tools/crosstool/
>
> Is it suitable for testing?
Yeah, as I said this is not specific to compiler version, just the combination of
build options which trigger it.
....
>>> so I removed CONFIG_EZNPS_GIC. And then I ended with:
>>> | LD vmlinux.o
>>> |arc-linux-ld: gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o): compiled for a little endian system and target is big endian
>>> |arc-linux-ld: failed to merge target specific data of file gcc-10.1.0-nolibc/arc-linux/bin/../lib/gcc/arc-linux/10.1.0/arc700/libgcc.a(_muldi3.o)
>>
>> This is unrelated since original .config with CONFIG_ARC_PLAT_EZNPS would have
>> selected Big endina build, but you need a BE toolchain to get that working (since
>> libgcc emulation code still comes from toolchain).
>
> Is a switch missing while building the gcc, another gcc target needed or
> is this something that is not part of upstream gcc?
You need a ARC gcc toolchain configured for big endian builds (actually the
compiler driver can handle both, but support libs such as libgcc need to be BE/LE
built either through multilib or cleanest is to have a ARC gcc configured for
big-endian. Everything is upstream.
>>> Please update CI and ARC.
>>
>> Nothing to update in CI. I'll send the ARC patch as a follow up.
>
> but it shouldn't complain about a commit merged in v5.7-rc1 because it
> caused an error which was then fixed in v5.7-rc7 while using HEAD
> v5.9-rc2?
Yeah this indeed is weird, the only explanation I can think of is the rand config
triggered the issue now.
-Vineet