[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58B5B934.5040807@codesourcery.com>
Date: Tue, 28 Feb 2017 10:53:56 -0700
From: Sandra Loosemore <sandra@...esourcery.com>
To: Tobias Klauser <tklauser@...tanz.ch>,
Guenter Roeck <linux@...ck-us.net>
CC: Sven Schmidt <4sschmid@...ormatik.uni-hamburg.de>,
Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>,
<linux-kernel@...r.kernel.org>, Ley Foon Tan <lftan@...era.com>,
<nios2-dev@...ts.rocketboards.org>
Subject: Re: nios2 crash/hang in mainline due to 'lib: update LZ4 compressor
module'
On 02/28/2017 08:53 AM, Tobias Klauser wrote:
> (adding Sandra Loosemore to Cc due to possible relation to gcc/binutils
> for nios2)
>
> On 2017-02-26 at 22:03:38 +0100, Guenter Roeck <linux@...ck-us.net> wrote:
>> Hi Sven,
>>
>> my qemu test for nios2 started failing with commit 4e1a33b105dd ("lib:
>> update LZ4 compressor module"). The test hangs early during boot before
>> any console output is seen. Reverting the offending patch as well as the
>> subsequent lz4 related patches fixes the problem. Disabling CONFIG_RD_LZ4
>> and with it other LZ4 options also fixes it (as does adding "return -EINVAL;"
>> at the top of the LZ4 decompression code). For reference, bisect log
>> is attached.
>>
>> I tried with buildroot toolchains using gcc 6.1.0 as well as 6.3.0
>> and binutils 2.26.1. Scripts used to run the tests are available at
>> https://github.com/groeck/linux-build-test/tree/master/rootfs/nios2.
>> Qemu is from qemu mainline or qemu v2.8 with nios2 patches applied.
>
> Looks like this is somehow related to gcc/binutils. Using GCC 4.8.3 and
> binutils 2.24.51 (both from from Sourcery CodeBench Lite 2014.05) I can
> get a kernel booting on latest master branch. AFAICT, none of the
> LZ4_decompress_* functions are called during boot.
>
> However, using a self-built GCC 7.0 (20161127) and binutils 2.27 I can
> reproduce the problem you see using the instructions Guenter provided in
> the reply to Sven.
>
> I'll try to dig a bit deeper from here on. Any suggestions on what to
> look out for wrt the differences between the gcc/binutils version are
> welcome of course.
This message doesn't give me enough context to know what is going on,
especially without seeing the rest of the thread. Generally speaking,
Mentor recommends you use one of our stable releases instead of trying
to roll your own from mainline sources. As an upstream binutils and gcc
maintainer I do try my best to look at bug reports for those components,
but I need a reproducible standalone testcase and specific versions of
the different components involved.
-Sandra
Powered by blists - more mailing lists