Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:

> mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> 
>     allnoconfig: FAIL
>     generic_defconfig: FAIL
>     ip27_defconfig: FAIL
>     tinyconfig: FAIL

These MIPS builds have been failing in kernelci ever since MIPS was
added.  This means that we've got a constant level of noise in the
results which makes them less useful for everyone - people get used to
ignoring errors.  Is there any plan to get these fixed?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Ralf Baechle]

On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:

> On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:
> 
> > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> > 
> >     allnoconfig: FAIL
> >     generic_defconfig: FAIL
> >     ip27_defconfig: FAIL
> >     tinyconfig: FAIL
> 
> These MIPS builds have been failing in kernelci ever since MIPS was
> added.  This means that we've got a constant level of noise in the
> results which makes them less useful for everyone - people get used to
> ignoring errors.  Is there any plan to get these fixed?

I wonder if these are also toolchain-related issues.  allnoconfig and
tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.

generic_defconfig requires mkimage of uboot-tools or it will fail like this:

  ITB     arch/mips/boot/vmlinux.gz.itb
"mkimage" command not found - U-Boot images will not be built
arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed
make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1
arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed
make: *** [vmlinux.gz.itb] Error 2

ip27_defconfig indeed has a build issue but it's new for 4.9 (commit
3ffc17d8768be705e292ac4c2e3ab1f18dc06047 ("MIPS: Adjust MIPS64 CAC_BASE to
reflect Config.K0")).  And with that patch reverted GCC 6.1.0 blows up with
an internal compilter error:

  CC [M]  drivers/net/ethernet/qlogic/qlge/qlge_main.o
drivers/net/ethernet/qlogic/qlge/qlge_main.c: In function ‘qlge_probe’:
drivers/net/ethernet/qlogic/qlge/qlge_main.c:4812:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 1373 1371 1361 79 (parallel [
            (set (reg/f:DI 3 $3 [490])
                (symbol_ref:DI ("delayed_work_timer_fn") [flags 0x241] <function_decl 0x7fdb8658ed20 delayed_work_timer_fn>))
            (clobber (scratch:DI))
        ]) drivers/net/ethernet/qlogic/qlge/qlge_main.c:4690 287 {*lea64}
     (nil))
drivers/net/ethernet/qlogic/qlge/qlge_main.c:4812:1: internal compiler error: in extract_constrain_insn, at recog.c:2190
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

GCC 6.2.0 dies the same way.

What binutils are you using and can you send me the build errors messages?

Thanks,

  Ralf

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

On Wed, Dec 14, 2016 at 05:06:09PM +0100, Ralf Baechle wrote:
> On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:
> > On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:

> > > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)

> > These MIPS builds have been failing in kernelci ever since MIPS was
> > added.  This means that we've got a constant level of noise in the
> > results which makes them less useful for everyone - people get used to
> > ignoring errors.  Is there any plan to get these fixed?

> I wonder if these are also toolchain-related issues.  allnoconfig and
> tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.

> generic_defconfig requires mkimage of uboot-tools or it will fail like this:

>   ITB     arch/mips/boot/vmlinux.gz.itb
> "mkimage" command not found - U-Boot images will not be built
> arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed
> make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1
> arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed
> make: *** [vmlinux.gz.itb] Error 2

Ah, you don't have a separate uImage target?

> What binutils are you using and can you send me the build errors messages?

You can see logs for all the trees we build via the web interface:

   https://kernelci.org/job/

I don't have access to the builders to check the binutils version
without going and finding/downloading the CodeSourcery release.  Where
did your toolchain come from, is there something specific recommended
for MIPS?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Arnd Bergmann]

On Wednesday, December 14, 2016 5:45:39 PM CET Mark Brown wrote:
> On Wed, Dec 14, 2016 at 05:06:09PM +0100, Ralf Baechle wrote:
> > On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:
> > > On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:
> 
> > > > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> 
> > > These MIPS builds have been failing in kernelci ever since MIPS was
> > > added.  This means that we've got a constant level of noise in the
> > > results which makes them less useful for everyone - people get used to
> > > ignoring errors.  Is there any plan to get these fixed?
> 
> > I wonder if these are also toolchain-related issues.  allnoconfig and
> > tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.
> 
> > generic_defconfig requires mkimage of uboot-tools or it will fail like this:
> 
> >   ITB     arch/mips/boot/vmlinux.gz.itb
> > "mkimage" command not found - U-Boot images will not be built
> > arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed
> > make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1
> > arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed
> > make: *** [vmlinux.gz.itb] Error 2
> 
> Ah, you don't have a separate uImage target?
> 
> > What binutils are you using and can you send me the build errors messages?
> 
> You can see logs for all the trees we build via the web interface:
> 
>    https://kernelci.org/job/
> 
> I don't have access to the builders to check the binutils version
> without going and finding/downloading the CodeSourcery release.  Where
> did your toolchain come from, is there something specific recommended
> for MIPS?
> 

From the web interface:

| Errors Summary
|
| 2	arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE" redefined [-Werror]
| 1	{standard input}:191: Error: number (0x9000000080000000) larger than 32 bits
| 1	{standard input}:164: Error: number (0x9000000080000000) larger than 32 bits
| 1	{standard input}:154: Error: number (0x9000000080000000) larger than 32 bits
| 1	{standard input}:139: Error: number (0x9000000080000000) larger than 32 bits
| 1	{standard input}:131: Error: number (0x9000000080000000) larger than 32 bits

This already got better than it was. I haven't analyzed them at all,
but I had not expected them to be toolchain related. The first one is
for ip27_defconfig, the other ones are for allnoconfig/tinyconfig.

The allmodconfig build had a lot more warnings, and was disabled
in kernelci a long time ago.

| Warnings Summary
|
| 2	arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
| 2	arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP

Lots of these, from defconfigs that need a trivial update

1	net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/ti/cpmac.c:1213:2: warning: #warning FIXME: unhardcode gpio&reset bits [-Wcpp]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c:748:1: warning: the frame size of 4704 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c:970:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c:1021:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c:621:1: warning: the frame size of 3616 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c:2753:1: warning: the frame size of 10768 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c:641:1: warning: the frame size of 5728 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c:419:1: warning: the frame size of 2912 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1	drivers/net/ethernet/broadcom/bcm63xx_enet.c:1130:3: warning: 'phydev' may be used uninitialized in this function [-Wmaybe-uninitialized]
1	drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of 'strncpy' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]

| 1	crypto/wp512.c:987:1: warning: the frame size of 1568 bytes is larger than 1024 bytes [-Wframe-larger-than=]
| 1	crypto/wp512.c:987:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
| 1	crypto/wp512.c:987:1: warning: the frame size of 1264 bytes is larger than 1024 bytes [-Wframe-larger-than=]
| 1	crypto/serpent_generic.c:436:1: warning: the frame size of 1472 bytes is larger than 1024 bytes [-Wframe-larger-than=]
| 1	crypto/serpent_generic.c:436:1: warning: the frame size of 1456 bytes is larger than 1024 bytes [-Wframe-larger-than=]

I've played around with these, it's possibly a gcc bug. This fixes one of them,
but breaks older toolchains that didn't have those options:

@@ -779,7 +779,10 @@ static const u64 rc[WHIRLPOOL_ROUNDS] = {
  * The core Whirlpool transform.
  */
 
-static void wp512_process_buffer(struct wp512_ctx *wctx) {
+static void
+__attribute__((optimize("-fno-sched-critical-path-heuristic")))
+__attribute__((optimize("-fno-sched-dep-count-heuristic")))
+wp512_process_buffer(struct wp512_ctx *wctx) {
        int i, r;
        u64 K[8];        /* the round key */
        u64 block[8];    /* mu(buffer) */

| 1	arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not used [-Wunused-function]
| 1	arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not used [-Wunused-function]
| 1	arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not used [-Wunused-function]
| 1	arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this function [-Wuninitialized]
| 1	arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this function [-Wuninitialized]

These are obvious bugs, fix should be trivial

| 1	arch/mips/netlogic/common/smpboot.S:63: Warning: dla used to load 32-bit register; recommend using la instead
| 1	arch/mips/netlogic/common/smpboot.S:62: Warning: dla used to load 32-bit register; recommend using la instead

Probably toolchain related, but should not be hard to fix up for
older toolchains.

	ARnd

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Arnd Bergmann]

On Wednesday, December 14, 2016 5:45:39 PM CET Mark Brown wrote:
> On Wed, Dec 14, 2016 at 05:06:09PM +0100, Ralf Baechle wrote:
> > On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:
> > > On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:
> 
> > > > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> 
> > > These MIPS builds have been failing in kernelci ever since MIPS was
> > > added.  This means that we've got a constant level of noise in the
> > > results which makes them less useful for everyone - people get used to
> > > ignoring errors.  Is there any plan to get these fixed?
> 
> > I wonder if these are also toolchain-related issues.  allnoconfig and
> > tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.
> 
> > generic_defconfig requires mkimage of uboot-tools or it will fail like this:
> 
> >   ITB     arch/mips/boot/vmlinux.gz.itb
> > "mkimage" command not found - U-Boot images will not be built
> > arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed
> > make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1
> > arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed
> > make: *** [vmlinux.gz.itb] Error 2
> 
> Ah, you don't have a separate uImage target?
> 
> > What binutils are you using and can you send me the build errors messages?
> 
> You can see logs for all the trees we build via the web interface:
> 
>    https://kernelci.org/job/
> 
> I don't have access to the builders to check the binutils version
> without going and finding/downloading the CodeSourcery release.  Where
> did your toolchain come from, is there something specific recommended
> for MIPS?
> 

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Ralf Baechle]

On Wed, Dec 14, 2016 at 05:45:39PM +0000, Mark Brown wrote:
> Date:   Wed, 14 Dec 2016 17:45:39 +0000
> From: Mark Brown <broonie@kernel.org>
> To: Ralf Baechle <ralf@linux-mips.org>
> Cc: kernel-build-reports@lists.linaro.org, linux-mips@linux-mips.org
> Subject: Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82
>  warnings (next-20161214)
> Content-Type: multipart/signed; micalg=pgp-sha256;
>         protocol="application/pgp-signature"; boundary="pme7352aoyqgs7t5"
> 
> On Wed, Dec 14, 2016 at 05:06:09PM +0100, Ralf Baechle wrote:
> > On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:
> > > On Wed, Dec 14, 2016 at 12:39:18AM -0800, kernelci.org bot wrote:
> 
> > > > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> 
> > > These MIPS builds have been failing in kernelci ever since MIPS was
> > > added.  This means that we've got a constant level of noise in the
> > > results which makes them less useful for everyone - people get used to
> > > ignoring errors.  Is there any plan to get these fixed?
> 
> > I wonder if these are also toolchain-related issues.  allnoconfig and
> > tinyconfig do build fine for me with GCC 6.1.0 and binutils 2.26.20160125.
> 
> > generic_defconfig requires mkimage of uboot-tools or it will fail like this:
> 
> >   ITB     arch/mips/boot/vmlinux.gz.itb
> > "mkimage" command not found - U-Boot images will not be built
> > arch/mips/boot/Makefile:159: recipe for target 'arch/mips/boot/vmlinux.gz.itb' failed
> > make[1]: *** [arch/mips/boot/vmlinux.gz.itb] Error 1
> > arch/mips/Makefile:365: recipe for target 'vmlinux.gz.itb' failed
> > make: *** [vmlinux.gz.itb] Error 2
> 
> Ah, you don't have a separate uImage target?
> 
> > What binutils are you using and can you send me the build errors messages?
> 
> You can see logs for all the trees we build via the web interface:
> 
>    https://kernelci.org/job/
> 
> I don't have access to the builders to check the binutils version
> without going and finding/downloading the CodeSourcery release.  Where
> did your toolchain come from, is there something specific recommended
> for MIPS?

I specifically avoid non-standard toolchains, that is I stick to the
vanilla FSF releases with no feature patches.

Some configurations, in particular new cores or architecture variants
may require vendor tool- chains or patches until support makes it upstream.
I wonder if for the benefit of automated build testing we should tag
kernel configurations with a special CONFIG_ symbol to indicate they need
non-standard tools?  That would allow build testing to detect and
possibly skip such configuration.

  Ralf

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Arnd Bergmann]

On Thursday, December 15, 2016 4:22:41 AM CET Ralf Baechle wrote:
> 
> Some configurations, in particular new cores or architecture variants
> may require vendor tool- chains or patches until support makes it upstream.
> I wonder if for the benefit of automated build testing we should tag
> kernel configurations with a special CONFIG_ symbol to indicate they need
> non-standard tools?  That would allow build testing to detect and
> possibly skip such configuration.

I think that this ties in with a discussion we recently had about moving
toolchain feature detection from Makefiles into Kconfig, which can
then probably handle this better. We just need to find someone who
can hack this up into Kconfig.

	Arnd

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

On Thu, Dec 15, 2016 at 04:22:41AM +0100, Ralf Baechle wrote:
> On Wed, Dec 14, 2016 at 05:45:39PM +0000, Mark Brown wrote:

> > without going and finding/downloading the CodeSourcery release.  Where
> > did your toolchain come from, is there something specific recommended
> > for MIPS?

> I specifically avoid non-standard toolchains, that is I stick to the
> vanilla FSF releases with no feature patches.

We're really looking for prebuilt binaries here, if nothing else it
makes it a lot easier to debug problems if people are using exactly the
same binary as it eliminates the possibility of differences in the
builds (due to some dependency changing for example).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Ralf Baechle]

On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:

> > mips:    gcc version 5.3.0 (Sourcery CodeBench Lite 2016.05-8)
> > 
> >     allnoconfig: FAIL
> >     generic_defconfig: FAIL
> >     ip27_defconfig: FAIL
> >     tinyconfig: FAIL
> 
> These MIPS builds have been failing in kernelci ever since MIPS was
> added.  This means that we've got a constant level of noise in the
> results which makes them less useful for everyone - people get used to
> ignoring errors.  Is there any plan to get these fixed?

I had to "bisect" binutils versions to hit the allnoconfig and tinyconfig
build issues.  Turns out it's a problem specific to binutils 2.25 which
when generating 32 bit ELF does not permit the use of 64 bit constants,
not even when explicitly to the 64 bit instruction set, for example:

	.set	mips3
	dli	$1, 0x9000000080000000

The only fix I was able to find that will work with all binutils, is
open coding the dli macro instruction as

	li	$1, 0x9000
	dsll	$1, $1, 48

Which is pretty much what the assembler should have generated from the dli
anyway.

  Ralf

Re: next build: 198 builds: 4 failed, 194 passed, 7 errors, 82 warnings (next-20161214)

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

On Fri, Dec 16, 2016 at 01:56:06AM +0100, Ralf Baechle wrote:
> On Wed, Dec 14, 2016 at 01:52:14PM +0000, Mark Brown wrote:

> > These MIPS builds have been failing in kernelci ever since MIPS was
> > added.  This means that we've got a constant level of noise in the
> > results which makes them less useful for everyone - people get used to
> > ignoring errors.  Is there any plan to get these fixed?

> I had to "bisect" binutils versions to hit the allnoconfig and tinyconfig
> build issues.  Turns out it's a problem specific to binutils 2.25 which
> when generating 32 bit ELF does not permit the use of 64 bit constants,
> not even when explicitly to the 64 bit instruction set, for example:

> 	.set	mips3
> 	dli	$1, 0x9000000080000000

> The only fix I was able to find that will work with all binutils, is
> open coding the dli macro instruction as

> 	li	$1, 0x9000
> 	dsll	$1, $1, 48

> Which is pretty much what the assembler should have generated from the dli
> anyway.

Thanks - someone should probably tell the purpl people, it's their
toolchain we're currently using.  We did have a bit of a look yesterday
for other prebuilt ones but didn't come up with anything so I guess a
lot of people are going to be using that one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]