[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55F46630.1090807@roeck-us.net>
Date: Sat, 12 Sep 2015 10:51:44 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Max Filippov <jcmvbkbc@...il.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
shuah.kh@...sung.com,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH 3.10 00/11] 3.10.88-stable review
On 09/12/2015 10:36 AM, Sudip Mukherjee wrote:
> On Sat, Sep 12, 2015 at 07:22:39PM +0300, Max Filippov wrote:
>> On Sat, Sep 12, 2015 at 6:55 PM, Greg Kroah-Hartman
>> <gregkh@...uxfoundation.org> wrote:
>>> On Sat, Sep 12, 2015 at 12:56:03PM +0530, Sudip Mukherjee wrote:
>>>> On Fri, Sep 11, 2015 at 03:48:59PM -0700, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 3.10.88 release.
>>>>> There are 11 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Sun Sep 13 22:45:08 UTC 2015.
>>>>> Anything received after that time might be too late.
>>>> Compiled and booted on x86_32. No errors in dmesg.
>>>>
>>>> cross_compiled with allmodconfig:
>> ...
>>>> xtensa - failed
>>>
>>> Are these all new failures?
>>
>> Build log says
>>
>> /home/travis/local/gcc-4.9.0-nolibc/xtensa-linux/bin/xtensa-linux-objcopy:
>> Unable to change endianness of input file(s)
>> make[2]: *** [arch/xtensa/boot/boot-elf/Image.o] Error 1
>>
>> which looks like misconfigured toolchain.
> But the same script and same toolchain compiles properly for 4.1.7-rc1,
> 3.14.52-rc1 and also works for Linus tree (last tested yesterday
> morning). I will see what has changed between 3.10 and 3.14 so that it
> doesnot work for 3.10 but works for 3.14.
>
The question here is if this is a new failure in 3.10, not if it has been
fixed in a later kernel version.
For my part I used to report such persistent failures. However, I find it
useless and even confusing to report "yep, still fails", unless there is
a plan to fix it, so I don't do that anymore. Otherwise it is just a waste
of test resources, and it makes it difficult to understand the test summary.
If I _do_ report such failures, I track down the cause and the fix, and ask
the branch maintainer to apply the necessary patch(es).
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists