Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20171115085933.GA25434@kroah.com>
References: <20171113125557.613444087@linuxfoundation.org> <C753778F-4F4D-42A0-821A-7FEDE28D6985@linaro.org>
 <20171115085933.GA25434@kroah.com>
From:   Milosz Wasilewski <milosz.wasilewski@linaro.org>
Date:   Wed, 15 Nov 2017 10:14:55 +0000
Message-ID: <CAJrz+7KVkPMcSo4xHPOv17_7w=gs2ASAMQXYfUJE1x=w-m5Xcw@mail.gmail.com>
Subject: Re: [PATCH 4.4 00/56] 4.4.98-stable review
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Tom Gall <tom.gall@linaro.org>,
        LKML <linux-kernel@vger.kernel.org>,
        torvalds@linux-foundation.org, akpm@linux-foundation.org,
        Guenter Roeck <linux@roeck-us.net>,
        Shuah Khan <shuahkh@osg.samsung.com>, patches@kernelci.org,
        Ben Hutchings <ben.hutchings@codethink.co.uk>,
        linux- stable <stable@vger.kernel.org>,
        Naresh Kamboju <naresh.kamboju@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 15 November 2017 at 08:59, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Nov 14, 2017 at 03:31:18PM -0600, Tom Gall wrote:
>>
>>
>> > On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman <gregkh@linuxfoundatio=
n.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.98 release.
>> > There are 56 patches in this series, all will be posted as a response
>> > to this one.  If anyone has any issues with these being applied, pleas=
e
>> > let me know.
>> >
>> > Responses should be made by Wed Nov 15 12:55:32 UTC 2017.
>> > Anything received after that time might be too late.
>> >
>> > The whole patch series can be found in one patch at:
>> >     kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.98-rc1.gz
>> > or in the git tree and branch at:
>> >  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.=
git linux-4.4.y
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>> >
>>
>> Results from Linaro=E2=80=99s test farm. One regression detected on x86.=
 We=E2=80=99re doing some re-runs to see if it=E2=80=99s a solid failure or=
 intermittent. It is however a testcase which hasn=E2=80=99t failed in the =
past.  Also as per usual the HiKey results are reported separate because th=
e platform support isn=E2=80=99t in tree.
>
> I thought I gave you enough \n in the past, did you use all of them up?  =
:(
>
> Anyway, what is the new x86 failure?
>
> Is it this:
>
>> * ltp-syscalls-tests - skip: 164, fail: 4, pass: 957

It's
readahead02    0  TINFO  :  creating test file of size: 67108864
readahead02    0  TINFO  :  read_testfile(0)
readahead02    0  TINFO  :  read_testfile(1)
readahead02    0  TINFO  :  max ra estimate: 262144
readahead02    0  TINFO  :  readahead calls made: 256
readahead02    1  TPASS  :  offset is still at 0 as expected
readahead02    0  TINFO  :  read_testfile(0) took: 951656 usec
readahead02    0  TINFO  :  read_testfile(1) took: 921704 usec
readahead02    0  TINFO  :  read_testfile(0) read: 67108864 bytes
readahead02    0  TINFO  :  read_testfile(1) read: 51257344 bytes
readahead02    2  TPASS  :  readahead saved some I/O
readahead02    0  TINFO  :  cache can hold at least: 86180 kB
readahead02    0  TINFO  :  read_testfile(0) used cache: 65308 kB
readahead02    0  TINFO  :  read_testfile(1) used cache: 15332 kB
readahead02    0  TWARN  :  readahead02.c:351: using less cache than expect=
ed

Source of the test:
https://github.com/linux-test-project/ltp/blob/20170929/testcases/kernel/sy=
scalls/readahead/readahead02.c#L351

It's the first time this test failed since we started running it. I'll
ask Naresh to look into it.

>
> If so, any pointers to the specific log messages, and which tests are
> failing?  Digging through the web site isn't the easiest...
>
> And kselftests should have gotten less failures this time around, given
> that some of them were patched in this -rc, why didn't that number go
> down?

Do you mean the tests were patched or the kernel code that was
exercised? If it's the former, it won't have effect as we're using the
kselftests sources from 4.13

milosz

From 1584122066453739391@xxx Wed Nov 15 09:02:08 +0000 2017
X-GM-THRID: 1583958255601886035
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread