Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman 
>>> <gre...@linuxfoundation.org> wrote:
>>> 
>>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>>>> 
>>>> 
>>>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman 
>>>>> <gre...@linuxfoundation.org> wrote:
>>>>> 
>>>>> This is the start of the stable review cycle for the 4.14.4 release.
>>>>> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
>>>>> and the diffstat can be found below.
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> greg k-h
>>>>> 
>>>> 
>>>> Compiled, booted and ran the following package unit tests without 
>>>> regressions on x86_64
>>>> 
>>>> boringssl : 
>>>>  go test target:0/0/5764/5764/5764 PASS
>>>>  ssl_test : 10 pass
>>>>  crypto_test : 28 pass
>>>> e2fsprogs:
>>>>  make check : 340 pass
>>>> sqlite
>>>>  make test : 143914 pass
>>>> drm
>>>>  make check : 15 pass
>>>>  modetest, drmdevice : pass
>>>> alsa-lib
>>>>  make check : 2 pass
>>>> bluez
>>>>  make check : 25 pass
>>>> libusb
>>>>  stress : 4 pass
>>> 
>>> How do the above tests stress the kernel?
>> 
>> Depends entirely on the package in question.
>> 
>> Sure, of completely no surprise a lot of package unit tests don’t really 
>> do much that’s particularly interesting save to the package itself.
> 
> Then why run those tests?  Like sqlite, what kernel functionality does
> that exercise that ltp does not?

Simply it beats on the system. 

>> There are sometimes an interesting subset that drives some amount of work in 
>> kernel. 
>> That’s the useful stuff.
> 
> Is that true with the above list?  If so, why are those types of tests
> not part of any kernel test suite that I have seen before?

Dunno. Can’t comment on the non-action by others. What we can do is either
harvest (by adding to say LTP) or improve in the 

> 
>> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.  
> 
> Nice, does that cover things that is not in LTP?  Should those tests be
> added to LTP?
> 
>>> Aren't they just
>>> verifications that the source code in the package is correct?
>> 
>> So if there’s some useful subset, that’s what I’m looking for.
>> 
>>> I guess it proves something, but have you ever seen the above regress in
>>> _any_ kernel release?
>> 
>> Past regressions make for a good test. 
> 
> You are testing past regressions of the userspace code, not the kernel
> here.  Why do I care about that?  :)

Like you, I only care things that are testing the kernel. I’m lazy.  I’m not
chopping out the things that go far afield, besides it’s not broken nor is it
hurting anything.

> Don't fall down the trap of running code for the sake of running code
> (i.e. like that web site that starts with a P) that doesn't actually
> test anything that actually matters.

Yup entirely agree. No emerge world going on here. 8-b

> thanks,
> 
> greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 6, 2017, at 12:49 AM, Greg Kroah-Hartman  
> wrote:
> 
> On Tue, Dec 05, 2017 at 03:45:07PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman 
>>>  wrote:
>>> 
>>> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>>>> 
>>>> 
>>>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman 
>>>>>  wrote:
>>>>> 
>>>>> This is the start of the stable review cycle for the 4.14.4 release.
>>>>> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
>>>>> and the diffstat can be found below.
>>>>> 
>>>>> thanks,
>>>>> 
>>>>> greg k-h
>>>>> 
>>>> 
>>>> Compiled, booted and ran the following package unit tests without 
>>>> regressions on x86_64
>>>> 
>>>> boringssl : 
>>>>  go test target:0/0/5764/5764/5764 PASS
>>>>  ssl_test : 10 pass
>>>>  crypto_test : 28 pass
>>>> e2fsprogs:
>>>>  make check : 340 pass
>>>> sqlite
>>>>  make test : 143914 pass
>>>> drm
>>>>  make check : 15 pass
>>>>  modetest, drmdevice : pass
>>>> alsa-lib
>>>>  make check : 2 pass
>>>> bluez
>>>>  make check : 25 pass
>>>> libusb
>>>>  stress : 4 pass
>>> 
>>> How do the above tests stress the kernel?
>> 
>> Depends entirely on the package in question.
>> 
>> Sure, of completely no surprise a lot of package unit tests don’t really 
>> do much that’s particularly interesting save to the package itself.
> 
> Then why run those tests?  Like sqlite, what kernel functionality does
> that exercise that ltp does not?

Simply it beats on the system. 

>> There are sometimes an interesting subset that drives some amount of work in 
>> kernel. 
>> That’s the useful stuff.
> 
> Is that true with the above list?  If so, why are those types of tests
> not part of any kernel test suite that I have seen before?

Dunno. Can’t comment on the non-action by others. What we can do is either
harvest (by adding to say LTP) or improve in the 

> 
>> Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.  
> 
> Nice, does that cover things that is not in LTP?  Should those tests be
> added to LTP?
> 
>>> Aren't they just
>>> verifications that the source code in the package is correct?
>> 
>> So if there’s some useful subset, that’s what I’m looking for.
>> 
>>> I guess it proves something, but have you ever seen the above regress in
>>> _any_ kernel release?
>> 
>> Past regressions make for a good test. 
> 
> You are testing past regressions of the userspace code, not the kernel
> here.  Why do I care about that?  :)

Like you, I only care things that are testing the kernel. I’m lazy.  I’m not
chopping out the things that go far afield, besides it’s not broken nor is it
hurting anything.

> Don't fall down the trap of running code for the sake of running code
> (i.e. like that web site that starts with a P) that doesn't actually
> test anything that actually matters.

Yup entirely agree. No emerge world going on here. 8-b

> thanks,
> 
> greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
>>> wrote:
>>> 
>>> This is the start of the stable review cycle for the 4.14.4 release.
>>> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
>>> and the diffstat can be found below.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>>> 
>> 
>> Compiled, booted and ran the following package unit tests without 
>> regressions on x86_64
>> 
>> boringssl : 
>>   go test target:0/0/5764/5764/5764 PASS
>>   ssl_test : 10 pass
>>   crypto_test : 28 pass
>> e2fsprogs:
>>   make check : 340 pass
>> sqlite
>>   make test : 143914 pass
>> drm
>>   make check : 15 pass
>>   modetest, drmdevice : pass
>> alsa-lib
>>   make check : 2 pass
>> bluez
>>   make check : 25 pass
>> libusb
>>   stress : 4 pass
> 
> How do the above tests stress the kernel?

Depends entirely on the package in question.

Sure, of completely no surprise a lot of package unit tests don’t really 
do much that’s particularly interesting save to the package itself.

There are sometimes an interesting subset that drives some amount of work in 
kernel. 
That’s the useful stuff.

Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.  

>  Aren't they just
> verifications that the source code in the package is correct?

So if there’s some useful subset, that’s what I’m looking for.

> I guess it proves something, but have you ever seen the above regress in
> _any_ kernel release?

Past regressions make for a good test. 

> I know the drm developers have a huge test suite that they use to verify
> their kernel changes, why not use that?

Good feedback, thanks.

> thanks,
> 
> greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 5, 2017, at 12:24 AM, Greg Kroah-Hartman  
> wrote:
> 
> On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman  
>>> wrote:
>>> 
>>> This is the start of the stable review cycle for the 4.14.4 release.
>>> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
>>> and the diffstat can be found below.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>>> 
>> 
>> Compiled, booted and ran the following package unit tests without 
>> regressions on x86_64
>> 
>> boringssl : 
>>   go test target:0/0/5764/5764/5764 PASS
>>   ssl_test : 10 pass
>>   crypto_test : 28 pass
>> e2fsprogs:
>>   make check : 340 pass
>> sqlite
>>   make test : 143914 pass
>> drm
>>   make check : 15 pass
>>   modetest, drmdevice : pass
>> alsa-lib
>>   make check : 2 pass
>> bluez
>>   make check : 25 pass
>> libusb
>>   stress : 4 pass
> 
> How do the above tests stress the kernel?

Depends entirely on the package in question.

Sure, of completely no surprise a lot of package unit tests don’t really 
do much that’s particularly interesting save to the package itself.

There are sometimes an interesting subset that drives some amount of work in 
kernel. 
That’s the useful stuff.

Take bluez, and it’s use of CONFIG_CRYPTO_USER_API.  

>  Aren't they just
> verifications that the source code in the package is correct?

So if there’s some useful subset, that’s what I’m looking for.

> I guess it proves something, but have you ever seen the above regress in
> _any_ kernel release?

Past regressions make for a good test. 

> I know the drm developers have a huge test suite that they use to verify
> their kernel changes, why not use that?

Good feedback, thanks.

> thanks,
> 
> greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled, booted and ran the following package unit tests without regressions 
on x86_64

boringssl : 
   go test target:0/0/5764/5764/5764 PASS
   ssl_test : 10 pass
   crypto_test : 28 pass
e2fsprogs:
   make check : 340 pass
sqlite
   make test : 143914 pass
drm
   make check : 15 pass
   modetest, drmdevice : pass
alsa-lib
   make check : 2 pass
bluez
   make check : 25 pass
libusb
   stress : 4 pass

> 

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Tom Gall]

> On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 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 Wed Dec  6 16:00:27 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.14.4-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.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled, booted and ran the following package unit tests without regressions 
on x86_64

boringssl : 
   go test target:0/0/5764/5764/5764 PASS
   ssl_test : 10 pass
   crypto_test : 28 pass
e2fsprogs:
   make check : 340 pass
sqlite
   make test : 143914 pass
drm
   make check : 15 pass
   modetest, drmdevice : pass
alsa-lib
   make check : 2 pass
bluez
   make check : 25 pass
libusb
   stress : 4 pass

> 

Re: [PATCH 4.14 000/193] 4.14.3-stable review

[Tom Gall]

> On Nov 28, 2017, at 11:13 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Tue, Nov 28, 2017 at 04:17:08PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Nov 28, 2017, at 4:24 AM, Greg Kroah-Hartman 
>>> <gre...@linuxfoundation.org> wrote:
>>> 
>>> This is the start of the stable review cycle for the 4.14.3 release.
>>> There are 193 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 Thu Nov 30 10:05:26 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.14.3-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.14.y
>>> and the diffstat can be found below.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>>> 
>>> -
>>> 
>> 
>> Successfully runs the following package test suites on x86-64 without any 
>> errors:
>> alsa-lib
>> boringssl
>> e2fsprogs
>> libusb
>> sqlite
>> 
>> Signed-off-by: Tom Gall <tom.g...@linaro.org>
> 

s/Signed-off-by:/Tested-by:/

> What exactly are you signing off on here?  You do know what that line
> means, right?
> 
> totally confused,
> 
> greg k-h

Re: [PATCH 4.14 000/193] 4.14.3-stable review

[Tom Gall]

> On Nov 28, 2017, at 11:13 PM, Greg Kroah-Hartman  
> wrote:
> 
> On Tue, Nov 28, 2017 at 04:17:08PM -0600, Tom Gall wrote:
>> 
>> 
>>> On Nov 28, 2017, at 4:24 AM, Greg Kroah-Hartman 
>>>  wrote:
>>> 
>>> This is the start of the stable review cycle for the 4.14.3 release.
>>> There are 193 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 Thu Nov 30 10:05:26 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.14.3-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.14.y
>>> and the diffstat can be found below.
>>> 
>>> thanks,
>>> 
>>> greg k-h
>>> 
>>> -
>>> 
>> 
>> Successfully runs the following package test suites on x86-64 without any 
>> errors:
>> alsa-lib
>> boringssl
>> e2fsprogs
>> libusb
>> sqlite
>> 
>> Signed-off-by: Tom Gall 
> 

s/Signed-off-by:/Tested-by:/

> What exactly are you signing off on here?  You do know what that line
> means, right?
> 
> totally confused,
> 
> greg k-h

Re: [PATCH 4.14 000/193] 4.14.3-stable review

[Tom Gall]

> On Nov 28, 2017, at 4:24 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> This is the start of the stable review cycle for the 4.14.3 release.
> There are 193 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 Thu Nov 30 10:05:26 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.14.3-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.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -
> 

Successfully runs the following package test suites on x86-64 without any 
errors:
alsa-lib
boringssl
e2fsprogs
libusb
sqlite

Signed-off-by: Tom Gall <tom.g...@linaro.org>

Re: [PATCH 4.14 000/193] 4.14.3-stable review

[Tom Gall]

> On Nov 28, 2017, at 4:24 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.14.3 release.
> There are 193 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 Thu Nov 30 10:05:26 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.14.3-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.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -
> 

Successfully runs the following package test suites on x86-64 without any 
errors:
alsa-lib
boringssl
e2fsprogs
libusb
sqlite

Signed-off-by: Tom Gall 

Re: [LTP] Towards 4.14 LTS

[Tom Gall]

> On Nov 20, 2017, at 10:10 AM, Cyril Hrubis  wrote:
> 
> Hi!
>> So why didn???t we report these? As mentioned we???ve been tossing out dodgy
>> test cases to get to a clean baseline. We don???t need or want noise. 
>> 
>> For LTS, I want the system when it detects a failure to enable a quick 
>> bisect involving the affected test bucket. Given the nature of kernel 
>> bugs tho, there is that class of bug which only happens occasionally.
> 
> From my experience debugging kernel bugs requires an actuall human
> interaction and there is only certain level of automation that can be
> achieved. Don't take me wrong, automatic bisection and other bells and
> whistles are a nice to have, but at the end of the day you usually need
> someone to reproduce/look at the problem, possibly check the source
> code, report a bug, etc. Hence it does not make much sense to have an
> automated system without dedicated engineers assigned to review the test
> results.

You are entirely right automation only gets so far. We have a few lines
of defense that probably are worth a mention.

1) infra - sometimes results/runs need to be re-run for whatever reason.
2) triage - Crappy test case or something that is real?
3) kernel - bisecting etc

We don’t have huge dedicated teams for each category but likewise each 
has a team.

> -- 
> Cyril Hrubis
> chru...@suse.cz

Re: [LTP] Towards 4.14 LTS

[Tom Gall]

> On Nov 20, 2017, at 10:10 AM, Cyril Hrubis  wrote:
> 
> Hi!
>> So why didn???t we report these? As mentioned we???ve been tossing out dodgy
>> test cases to get to a clean baseline. We don???t need or want noise. 
>> 
>> For LTS, I want the system when it detects a failure to enable a quick 
>> bisect involving the affected test bucket. Given the nature of kernel 
>> bugs tho, there is that class of bug which only happens occasionally.
> 
> From my experience debugging kernel bugs requires an actuall human
> interaction and there is only certain level of automation that can be
> achieved. Don't take me wrong, automatic bisection and other bells and
> whistles are a nice to have, but at the end of the day you usually need
> someone to reproduce/look at the problem, possibly check the source
> code, report a bug, etc. Hence it does not make much sense to have an
> automated system without dedicated engineers assigned to review the test
> results.

You are entirely right automation only gets so far. We have a few lines
of defense that probably are worth a mention.

1) infra - sometimes results/runs need to be re-run for whatever reason.
2) triage - Crappy test case or something that is real?
3) kernel - bisecting etc

We don’t have huge dedicated teams for each category but likewise each 
has a team.

> -- 
> Cyril Hrubis
> chru...@suse.cz

Re: Towards 4.14 LTS

[Tom Gall]

> On Nov 19, 2017, at 5:20 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Thu, Nov 16, 2017 at 10:50:23PM -0600, Tom Gall wrote:
>> At Linaro we’ve been putting effort into regularly running kernel tests over 
>> arm, arm64 and x86_64 targets. On those targets we’re running mainline, 
>> -next, 
>> 4.4, and 4.9 kernels and yes we are adding to this list as the hardware 
>> capacity grows.
>> 
>> For test buckets we’re using just LTP, kselftest and libhugetlbfs and
>> like kernels we will add to this list. 
> 
> I'm sorry, I don't understand this sentance.

I was just saying that we intend to add more test buckets and more kernels.

For instance 4.13-rc just was added to the mix.

For test buckets, I’m currently dorking around with some make check targets
for a few interesting packages. 

> 
>> With the 4.14 cycle being a little ‘different’ in so much as the goal to 
>> have it be an LTS kernel I think it’s important to take a look at some 
>> 4.14 test results. 
>> 
>> Grab a beverage, this is a bit of a long post. But quick summery 4.14 as 
>> released looks just as good as 4.13, for the test buckets I named above.
> 
> Thanks for doing this testing and letting us know.
> 
> greg k-h

Re: Towards 4.14 LTS

[Tom Gall]

> On Nov 19, 2017, at 5:20 AM, Greg Kroah-Hartman  
> wrote:
> 
> On Thu, Nov 16, 2017 at 10:50:23PM -0600, Tom Gall wrote:
>> At Linaro we’ve been putting effort into regularly running kernel tests over 
>> arm, arm64 and x86_64 targets. On those targets we’re running mainline, 
>> -next, 
>> 4.4, and 4.9 kernels and yes we are adding to this list as the hardware 
>> capacity grows.
>> 
>> For test buckets we’re using just LTP, kselftest and libhugetlbfs and
>> like kernels we will add to this list. 
> 
> I'm sorry, I don't understand this sentance.

I was just saying that we intend to add more test buckets and more kernels.

For instance 4.13-rc just was added to the mix.

For test buckets, I’m currently dorking around with some make check targets
for a few interesting packages. 

> 
>> With the 4.14 cycle being a little ‘different’ in so much as the goal to 
>> have it be an LTS kernel I think it’s important to take a look at some 
>> 4.14 test results. 
>> 
>> Grab a beverage, this is a bit of a long post. But quick summery 4.14 as 
>> released looks just as good as 4.13, for the test buckets I named above.
> 
> Thanks for doing this testing and letting us know.
> 
> greg k-h

Towards 4.14 LTS

[Tom Gall]

At Linaro we’ve been putting effort into regularly running kernel tests over 
arm, arm64 and x86_64 targets. On those targets we’re running mainline, -next, 
4.4, and 4.9 kernels and yes we are adding to this list as the hardware 
capacity grows.

For test buckets we’re using just LTP, kselftest and libhugetlbfs and
like kernels we will add to this list. 

With the 4.14 cycle being a little ‘different’ in so much as the goal to 
have it be an LTS kernel I think it’s important to take a look at some 
4.14 test results. 

Grab a beverage, this is a bit of a long post. But quick summery 4.14 as 
released looks just as good as 4.13, for the test buckets I named above.

I’ve enclosed our short form report. We break down the boards/arch combos for
each bucket pass/skip or potentially fails. Pretty straight forward. Skips
generally happen for a few reasons
1) crappy test cases
2) test isn’t appropriate (x86 specific tests so don’t run elsewhere)

With this, we have a decent baseline for 4.14 and other kernels going
forward. 

Summary


kernel: 4.14.0
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git branch: master
git commit: bebc6082da0a9f5d47a1ea2edc099bf671058bd4
git describe: v4.14
Test details: https://qa-reports.linaro.org/lkft/linux-mainline-oe/build/v4.14


No regressions (compared to build v4.14-rc8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 16, pass: 38
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 983
* ltp-timers-tests - pass: 12

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 15, pass: 38
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, pass: 943
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 17, pass: 36
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 66, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 19
* kselftest - skip: 11, pass: 54
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 1
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 8
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 9
* ltp-securebits-tests - pass: 3
* ltp-syscalls-tests - skip: 163, pass: 962

Lots of green.


Let’s now talk about coverage, the pandora’s box of validation. It’s never
perfect. There’s a bazillion different build combos. Even tools can
make a difference. We’ve seen a case where the dhcp client from open embedded 
didn’t trigger a network regression in one of the LTS RCs but Debian’s dhclient
did.

Of no surprise between what we and others have, it’s not perfect coverage,
and there are only so many build, boot and run cycles to execute the test 
buckets with various combinations so we need to stay sensible as far as 
kernel configs go. 

Does this kind of system actually FIND anything and is it useful for 
watching for 4.14 regressions as fixes are introduced?

I would assert the answer is yes. We do have data for a couple of kernel
cycles but it’s also somewhat dirty as we have been in the process of 

Towards 4.14 LTS

[Tom Gall]

At Linaro we’ve been putting effort into regularly running kernel tests over 
arm, arm64 and x86_64 targets. On those targets we’re running mainline, -next, 
4.4, and 4.9 kernels and yes we are adding to this list as the hardware 
capacity grows.

For test buckets we’re using just LTP, kselftest and libhugetlbfs and
like kernels we will add to this list. 

With the 4.14 cycle being a little ‘different’ in so much as the goal to 
have it be an LTS kernel I think it’s important to take a look at some 
4.14 test results. 

Grab a beverage, this is a bit of a long post. But quick summery 4.14 as 
released looks just as good as 4.13, for the test buckets I named above.

I’ve enclosed our short form report. We break down the boards/arch combos for
each bucket pass/skip or potentially fails. Pretty straight forward. Skips
generally happen for a few reasons
1) crappy test cases
2) test isn’t appropriate (x86 specific tests so don’t run elsewhere)

With this, we have a decent baseline for 4.14 and other kernels going
forward. 

Summary


kernel: 4.14.0
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git branch: master
git commit: bebc6082da0a9f5d47a1ea2edc099bf671058bd4
git describe: v4.14
Test details: https://qa-reports.linaro.org/lkft/linux-mainline-oe/build/v4.14


No regressions (compared to build v4.14-rc8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 16, pass: 38
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 983
* ltp-timers-tests - pass: 12

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 15, pass: 38
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, pass: 943
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 17, pass: 36
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 66, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 19
* kselftest - skip: 11, pass: 54
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 1
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 8
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 9
* ltp-securebits-tests - pass: 3
* ltp-syscalls-tests - skip: 163, pass: 962

Lots of green.


Let’s now talk about coverage, the pandora’s box of validation. It’s never
perfect. There’s a bazillion different build combos. Even tools can
make a difference. We’ve seen a case where the dhcp client from open embedded 
didn’t trigger a network regression in one of the LTS RCs but Debian’s dhclient
did.

Of no surprise between what we and others have, it’s not perfect coverage,
and there are only so many build, boot and run cycles to execute the test 
buckets with various combinations so we need to stay sensible as far as 
kernel configs go. 

Does this kind of system actually FIND anything and is it useful for 
watching for 4.14 regressions as fixes are introduced?

I would assert the answer is yes. We do have data for a couple of kernel
cycles but it’s also somewhat dirty as we have been in the process of 

Re: [PATCH 4.9 00/87] 4.9.62-stable review

[Tom Gall]

> On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.62 release.
> There are 87 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 Wed Nov 15 12:55:40 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.9.62-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from Linaro’s test farm. I’ll make one note. As we had an infra issue 
during the 4.9.61 release (not the RC cycle) for the purposes of regression 
detection we’re using the 4.9.60 release as it’s data is more complete and 
provides a good comparison point. 

Summary


kernel: 4.9.62-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 75d0bdcc05d119f234333f7841d0b97d3230cec2
git describe: v4.9.61-88-g75d0bdcc05d1
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.61-88-g75d0bdcc05d1


No regressions (compared to build v4.9.60)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 10, fail: 7, pass: 37 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 985
* ltp-timers-tests - pass: 12

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 7, fail: 7, pass: 37  (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, pass: 943
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 12, fail: 6, pass: 35  (known failures)
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 66, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - skip: 10, fail: 6, pass: 52  (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 18
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 21
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 962
* ltp-timers-tests - pass: 11



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/87] 4.9.62-stable review

[Tom Gall]

> On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.62 release.
> There are 87 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 Wed Nov 15 12:55:40 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.9.62-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from Linaro’s test farm. I’ll make one note. As we had an infra issue 
during the 4.9.61 release (not the RC cycle) for the purposes of regression 
detection we’re using the 4.9.60 release as it’s data is more complete and 
provides a good comparison point. 

Summary


kernel: 4.9.62-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 75d0bdcc05d119f234333f7841d0b97d3230cec2
git describe: v4.9.61-88-g75d0bdcc05d1
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.61-88-g75d0bdcc05d1


No regressions (compared to build v4.9.60)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 10, fail: 7, pass: 37 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 985
* ltp-timers-tests - pass: 12

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 7, fail: 7, pass: 37  (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, pass: 943
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 12, fail: 6, pass: 35  (known failures)
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 66, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - skip: 10, fail: 6, pass: 52  (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 18
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 21
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 962
* ltp-timers-tests - pass: 11



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/56] 4.4.98-stable review

[Tom Gall]

> On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman  
> 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, please
> 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’s test farm. One regression detected on x86. We’re doing 
some re-runs to see if it’s a solid failure or intermittent. It is however a 
testcase which hasn’t failed in the past.  Also as per usual the HiKey results 
are reported separate because the platform support isn’t in tree.

Summary


kernel: 4.4.98-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 528c687b455dced176c5e4be9275fb5a2ccdd60a
git describe: v4.4.97-57-g528c687b455d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.97-57-g528c687b455d

Regressions (compared to build v4.4.96)


dell-poweredge-r200 - x86_64:
 ltp-syscalls-tests:
   * readahead02

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 8, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 159, fail: 3, pass: 937 (known failures)
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 12, fail: 12, pass: 29 (known failures)
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, fail: 3, pass: 1036 (known failures)
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - skip: 10, fail: 15, pass: 42 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957 
* ltp-timers-tests - pass: 12

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports



And the hikey results.

Summary


kernel: 4.4.98-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.98-rc1-hikey-20171113
git commit: 96176dea6d2c63d2f94877204d06f4d94b9e3b05
git describe: 4.4.98-rc1-hikey-20171113
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.98-rc1-hikey-20171113


No regressions (compared to build 4.4.96-rc1-hikey-20171031)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 10, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* 

Re: [PATCH 4.4 00/56] 4.4.98-stable review

[Tom Gall]

> On Nov 13, 2017, at 6:55 AM, Greg Kroah-Hartman  
> 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, please
> 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’s test farm. One regression detected on x86. We’re doing 
some re-runs to see if it’s a solid failure or intermittent. It is however a 
testcase which hasn’t failed in the past.  Also as per usual the HiKey results 
are reported separate because the platform support isn’t in tree.

Summary


kernel: 4.4.98-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 528c687b455dced176c5e4be9275fb5a2ccdd60a
git describe: v4.4.97-57-g528c687b455d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.97-57-g528c687b455d

Regressions (compared to build v4.4.96)


dell-poweredge-r200 - x86_64:
 ltp-syscalls-tests:
   * readahead02

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 8, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 159, fail: 3, pass: 937 (known failures)
* ltp-timers-tests - pass: 12

x15 - arm
* boot - pass: 20
* kselftest - skip: 12, fail: 12, pass: 29 (known failures)
* libhugetlbfs - skip: 1, pass: 87
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 2, pass: 20
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, fail: 3, pass: 1036 (known failures)
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - skip: 10, fail: 15, pass: 42 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 164, fail: 4, pass: 957 
* ltp-timers-tests - pass: 12

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports



And the hikey results.

Summary


kernel: 4.4.98-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.98-rc1-hikey-20171113
git commit: 96176dea6d2c63d2f94877204d06f4d94b9e3b05
git describe: 4.4.98-rc1-hikey-20171113
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.98-rc1-hikey-20171113


No regressions (compared to build 4.4.96-rc1-hikey-20171031)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 10, fail: 13, pass: 31 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - 

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Tom Gall]

> On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov  8 09:44:42 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.97-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’s test farm. As per usual HiKey results held separate 
because it’s platform support is out of tree.

Summary


kernel: 4.4.97-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 3a8149abdccbecc21c68451ee8ffd86b56ff3061
git describe: v4.4.96-41-g3a8149abdccb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.96-41-g3a8149abdccb


Boards, architectures and test suites:
-

juno-r2 - arm64

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, fail: 11, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, fail: 4, skip: 67  (known failures)
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 15, skip: 9  (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 959, fail: 3, skip: 164  (known failures)
* ltp-timers-tests - pass: 13,


Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Summary


kernel: 4.4.97-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.97-rc1-hikey-20171107
git commit: f9ac28c428c0ddaf64cca891932a283fcca26516
git describe: 4.4.97-rc1-hikey-20171107
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.97-rc1-hikey-20171107


No regressions (compared to build 4.4.96-rc1-hikey-20171031)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, fail: 13, skip: 9  (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, fail: 13, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, fail: 3, skip: 125  (known failures)
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/40] 4.4.97-stable review

[Tom Gall]

> On Nov 6, 2017, at 3:44 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.97 release.
> There are 40 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 Wed Nov  8 09:44:42 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.97-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’s test farm. As per usual HiKey results held separate 
because it’s platform support is out of tree.

Summary


kernel: 4.4.97-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 3a8149abdccbecc21c68451ee8ffd86b56ff3061
git describe: v4.4.96-41-g3a8149abdccb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.96-41-g3a8149abdccb


Boards, architectures and test suites:
-

juno-r2 - arm64

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, fail: 11, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, fail: 4, skip: 67  (known failures)
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 15, skip: 9  (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 959, fail: 3, skip: 164  (known failures)
* ltp-timers-tests - pass: 13,


Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Summary


kernel: 4.4.97-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.97-rc1-hikey-20171107
git commit: f9ac28c428c0ddaf64cca891932a283fcca26516
git describe: 4.4.97-rc1-hikey-20171107
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.97-rc1-hikey-20171107


No regressions (compared to build 4.4.96-rc1-hikey-20171031)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, fail: 13, skip: 9  (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, fail: 13, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 980, fail: 3, skip: 125  (known failures)
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/67] 4.9.61-stable review

[Tom Gall]

> On Nov 6, 2017, at 3:43 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.61 release.
> There are 67 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 Wed Nov  8 09:12:36 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.9.61-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from the Linaro test farm. Nothing out of the ordinary this time 
around. 

Summary


kernel: 4.9.61-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 053597a60ffcd1e1ebd59c2add9163d26bc0d438
git describe: v4.9.60-68-g053597a60ffc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.60-68-g053597a60ffc


Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 38, fail: 7, skip: 8 (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 76,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 986, skip: 122
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 37, fail: 8, skip: 6 (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 76,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 944, skip: 156
* ltp-timers-tests - pass: 11, fail: 2,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 36, fail: 6, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1039, fail: 2, skip: 66 (known failures)
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 52, fail: 6, skip: 9 (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 1,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 1,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 2,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 963, skip: 163
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/67] 4.9.61-stable review

[Tom Gall]

> On Nov 6, 2017, at 3:43 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.61 release.
> There are 67 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 Wed Nov  8 09:12:36 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.9.61-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from the Linaro test farm. Nothing out of the ordinary this time 
around. 

Summary


kernel: 4.9.61-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 053597a60ffcd1e1ebd59c2add9163d26bc0d438
git describe: v4.9.60-68-g053597a60ffc
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.60-68-g053597a60ffc


Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 38, fail: 7, skip: 8 (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 76,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 986, skip: 122
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 37, fail: 8, skip: 6 (known failures)
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 76,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 944, skip: 156
* ltp-timers-tests - pass: 11, fail: 2,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 36, fail: 6, skip: 11 (known failures)
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1039, fail: 2, skip: 66 (known failures)
* ltp-timers-tests - pass: 12,

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 52, fail: 6, skip: 9 (known failures)
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 1,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 1,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 2,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 963, skip: 163
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/20] 4.4.96-stable review

[Tom Gall]

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.96 release.
> There are 20 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 Thu Nov  2 09:55:01 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.96-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 the Linaro test farm. Two regressions observed. I don’t believe 
either are 
cause for alarm. 

Notes below:

-
Summary


kernel: 4.4.96-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 32458fcb7bd6ac2aa886713b7c2e128c9e80a730
git describe: v4.4.95-21-g32458fcb7bd6
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.95-21-g32458fcb7bd6

Regressions (compared to build v4.4.95)


x15 - arm:
 kselftest:
   * rtctest  - This test case has a past where it’s intermittently failed. I 
wouldn’t put
   much concern on this one.

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

 ltp-syscalls-tests:
   * getrandom02 - this one is new. It’s always passed before tho X15 is still 
a relatively new board in
  the farm. The log reports that the test timed 
out. We’ll triage this one further.

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - fail: 13, skip: 7, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - fail: 13, skip: 36, pass: 27  (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 4, skip: 159, pass: 938  (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - fail: 13, skip: 11, pass: 29 (known with the exception of rtctest)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 4, skip: 68, pass: 1035 (known with exception of 
getrandom02)
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 24, pass: 43  (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 3
* ltp-syscalls-tests - fail: 3, skip: 164, pass: 960  (known failures)
* ltp-timers-tests - pass: 13



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


The hikey results, reported separately as this kernel contained patches that 
were added for 
platform support.

No regressions (compared to build 4.4.95-rc2-hikey-20171025)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - fail: 13, skip: 9, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - fail: 13, skip: 36, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* 

Re: [PATCH 4.4 00/20] 4.4.96-stable review

[Tom Gall]

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.96 release.
> There are 20 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 Thu Nov  2 09:55:01 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.96-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 the Linaro test farm. Two regressions observed. I don’t believe 
either are 
cause for alarm. 

Notes below:

-
Summary


kernel: 4.4.96-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 32458fcb7bd6ac2aa886713b7c2e128c9e80a730
git describe: v4.4.95-21-g32458fcb7bd6
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.95-21-g32458fcb7bd6

Regressions (compared to build v4.4.95)


x15 - arm:
 kselftest:
   * rtctest  - This test case has a past where it’s intermittently failed. I 
wouldn’t put
   much concern on this one.

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

 ltp-syscalls-tests:
   * getrandom02 - this one is new. It’s always passed before tho X15 is still 
a relatively new board in
  the farm. The log reports that the test timed 
out. We’ll triage this one further.

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - fail: 13, skip: 7, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - fail: 13, skip: 36, pass: 27  (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 4, skip: 159, pass: 938  (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - fail: 13, skip: 11, pass: 29 (known with the exception of rtctest)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 4, skip: 68, pass: 1035 (known with exception of 
getrandom02)
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 24, pass: 43  (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 3
* ltp-syscalls-tests - fail: 3, skip: 164, pass: 960  (known failures)
* ltp-timers-tests - pass: 13



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


The hikey results, reported separately as this kernel contained patches that 
were added for 
platform support.

No regressions (compared to build 4.4.95-rc2-hikey-20171025)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - fail: 13, skip: 9, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - fail: 13, skip: 36, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* 

Re: [PATCH 4.9 00/23] 4.9.60-stable review

[Tom Gall]

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.60 release.
> There are 23 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 Thu Nov  2 09:55:07 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.9.60-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

From the Linaro test farm:

Summary


kernel: 4.9.60-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 0aea695df43ec4454c9bf076a1a7faf264eb074f
git describe: v4.9.59-24-g0aea695df43e
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.59-24-g0aea695df43e


No regressions (compared to build v4.9.59)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - fail: 7, skip: 8, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 986
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - fail: 7, skip: 6, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 2, skip: 156, pass: 943 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - fail: 6, skip: 11, pass: 36 (known failures)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 15, pass: 52 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 18
* ltp-fsx-tests - pass: 1
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 964
* ltp-timers-tests - pass: 12

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/23] 4.9.60-stable review

[Tom Gall]

> On Oct 31, 2017, at 4:55 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.60 release.
> There are 23 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 Thu Nov  2 09:55:07 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.9.60-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

From the Linaro test farm:

Summary


kernel: 4.9.60-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 0aea695df43ec4454c9bf076a1a7faf264eb074f
git describe: v4.9.59-24-g0aea695df43e
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.59-24-g0aea695df43e


No regressions (compared to build v4.9.59)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - fail: 7, skip: 8, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 986
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - fail: 7, skip: 6, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - fail: 2, skip: 156, pass: 943 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - fail: 6, skip: 11, pass: 36 (known failures)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, pass: 1040
* ltp-timers-tests - pass: 12

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 15, pass: 52 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 18
* ltp-fsx-tests - pass: 1
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 964
* ltp-timers-tests - pass: 12

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/27] 4.4.95-stable review

[Tom Gall]

> On Oct 24, 2017, at 7:57 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.95 release.
> There are 27 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 Thu Oct 26 12:57:00 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.95-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 the Linaro test farm. No regressions spotted.


Summary


kernel: 4.4.95-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: a2b7c8b78a72a2da81ce896fd498a3cdf63a5702
git describe: v4.4.94-28-ga2b7c8b78a72
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.94-28-ga2b7c8b78a72


No regressions (compared to build v4.4.93-47-gcc1d76b2d639)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 7, fail: 13, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures, test 
case setup issues)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 159, fail: 4, pass: 938 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 9, fail: 12, pass: 32 (known failures)
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 68, fail: 4, pass: 1036 (known failures)
* ltp-timers-tests - pass: 13

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 24, pass: 42 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 164, fail: 3, pass: 960 (known failures)
* ltp-timers-tests - pass: 13

As Hikey with 4.4 requires some platform enablement patches, we report it’s 
results separately.

Summary


kernel: 4.4.95-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.95-rc1-hikey-20171024
git commit: 342b31177c919b75bc683f9cb79b78132c17ffab
git describe: 4.4.95-rc1-hikey-20171024
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.95-rc1-hikey-20171024


No regressions (compared to build 4.4.94-rc1-hikey-20171019)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 9, fail: 13, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 125, fail: 3, pass: 980 (known failures)
* ltp-timers-tests - pass: 13

Documentation - 

Re: [PATCH 4.4 00/27] 4.4.95-stable review

[Tom Gall]

> On Oct 24, 2017, at 7:57 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.95 release.
> There are 27 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 Thu Oct 26 12:57:00 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.95-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 the Linaro test farm. No regressions spotted.


Summary


kernel: 4.4.95-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: a2b7c8b78a72a2da81ce896fd498a3cdf63a5702
git describe: v4.4.94-28-ga2b7c8b78a72
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.94-28-ga2b7c8b78a72


No regressions (compared to build v4.4.93-47-gcc1d76b2d639)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 7, fail: 13, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures, test 
case setup issues)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 159, fail: 4, pass: 938 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 9, fail: 12, pass: 32 (known failures)
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 68, fail: 4, pass: 1036 (known failures)
* ltp-timers-tests - pass: 13

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 24, pass: 42 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 164, fail: 3, pass: 960 (known failures)
* ltp-timers-tests - pass: 13

As Hikey with 4.4 requires some platform enablement patches, we report it’s 
results separately.

Summary


kernel: 4.4.95-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.95-rc1-hikey-20171024
git commit: 342b31177c919b75bc683f9cb79b78132c17ffab
git describe: 4.4.95-rc1-hikey-20171024
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.95-rc1-hikey-20171024


No regressions (compared to build 4.4.94-rc1-hikey-20171019)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 9, fail: 13, pass: 32 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - skip: 36, fail: 13, pass: 27 (known failures)
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 125, fail: 3, pass: 980 (known failures)
* ltp-timers-tests - pass: 13

Documentation - 

Re: [PATCH 4.9 00/48] 4.9.59-stable review

[Tom Gall]

> On Oct 24, 2017, at 8:03 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.59 release.
> There are 48 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 Thu Oct 26 12:57:14 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.9.59-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -

Results from the Linaro test farm. No regressions observed.



Summary


kernel: 4.9.59-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 54651838029d43fc051ee147b35e769fe662d28f
git describe: v4.9.58-49-g54651838029d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.58-49-g54651838029d


No regressions (compared to build v4.9.58)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 8, fail: 7, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 986
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 6, fail: 7, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59 (known failures)
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, fail: 2, pass: 943 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 8, fail: 8, pass: 36 (known)
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, fail: 2, pass: 1039 (known and being worked on)
* ltp-timers-tests - pass: 13

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 15, pass: 53 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 8
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 964
* ltp-timers-tests - pass: 13



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/48] 4.9.59-stable review

[Tom Gall]

> On Oct 24, 2017, at 8:03 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.59 release.
> There are 48 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 Thu Oct 26 12:57:14 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.9.59-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -

Results from the Linaro test farm. No regressions observed.



Summary


kernel: 4.9.59-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 54651838029d43fc051ee147b35e769fe662d28f
git describe: v4.9.58-49-g54651838029d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.58-49-g54651838029d


No regressions (compared to build v4.9.58)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20
* kselftest - skip: 8, fail: 7, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - skip: 1, pass: 21
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 14
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 122, pass: 986
* ltp-timers-tests - pass: 13

juno-r2 - arm64
* boot - pass: 20
* kselftest - skip: 6, fail: 7, pass: 38 (known failures)
* libhugetlbfs - skip: 1, pass: 90
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 76
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - fail: 2, pass: 59 (known failures)
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 10
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 156, fail: 2, pass: 943 (known failures)
* ltp-timers-tests - pass: 13

x15 - arm
* boot - pass: 20
* kselftest - skip: 8, fail: 8, pass: 36 (known)
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - pass: 60
* ltp-fs_bind-tests - pass: 2
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-io-tests - pass: 3
* ltp-ipc-tests - pass: 9
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - skip: 1, pass: 13
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 67, fail: 2, pass: 1039 (known and being worked on)
* ltp-timers-tests - pass: 13

dell-poweredge-r200 - x86_64
* boot - pass: 20
* kselftest - fail: 15, pass: 53 (known failures)
* libhugetlbfs - skip: 1, pass: 76
* ltp-cap_bounds-tests - pass: 2
* ltp-containers-tests - pass: 64
* ltp-fcntl-locktests-tests - pass: 2
* ltp-filecaps-tests - pass: 2
* ltp-fs-tests - skip: 1, pass: 61
* ltp-fs_bind-tests - pass: 1
* ltp-fs_perms_simple-tests - pass: 19
* ltp-fsx-tests - pass: 2
* ltp-hugetlb-tests - pass: 22
* ltp-io-tests - pass: 2
* ltp-ipc-tests - pass: 8
* ltp-math-tests - pass: 11
* ltp-nptl-tests - pass: 2
* ltp-pty-tests - pass: 4
* ltp-sched-tests - pass: 9
* ltp-securebits-tests - pass: 4
* ltp-syscalls-tests - skip: 163, pass: 964
* ltp-timers-tests - pass: 13



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

> On Oct 21, 2017, at 2:25 AM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> On Fri, Oct 20, 2017 at 11:54:38AM -0500, Tom Gall wrote:
>> On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
>>>> fcntl36 and raw_skew we’ll looking into.
>>>> 
>>>> ltp-timers-tests:
>>>>   * leapsec_timer
>>>>   * runltp_timers
>>>> 
>>>>   * test src: git://github.com/linux-test-project/ltp.git
>>>> 
>>>> This one has been working and just failed with this RC cycle. It’s only 
>>>> failing on 32 bit arm.
>>>> 
>>>> Needs to be looked into.
>>> 
>>> When you say "Needs to be looked into", does that mean that you are
>>> pointing this out for someone else to do this (i.e. help, someone look
>>> at this!), or are you going to be working to figure it out?
>> 
>> Help is always great. We've got it covered.
>> 
>> One of the team that works on this board has been looking into it.
>> 
>> As of this second, and looking within the context of 4.4, 4.9 and mainline 
>> data
>> what we're looking at is intermitted failures involving raw_skew from
>> kselftest and leapsec_timer
>> from ltp_timers that is present across all those 3 kernel version and
>> their respective streams.
>> (by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
>> 
>> As such we can rule these out detecting a regression in the new RC
>> patches. Likely it's board
>> specific.
> 
> Side note, your use of \n is still really odd.  I strongly recommend
> getting a decent email client, or an sane editor that knows what to do
> here….

That email client has been sacked.

> Anyway, if you have board-specific issues, that are not -rc issues, can
> you say so really obviously so I don't worry that I broke something?
> Otherwise it's pretty annoying, as your email implies that I did
> something wrong, and only a few emails in the thread later will it come
> out that this is flaky hardware/tests so there's nothing to worry about.

Reports are pretty new & shiny yet so yes I’m over explaining the logic. 
To me, showing your work applies to other places besides math.

> The kernel.ci reports are a bit like this, I glance at them and only
> worry if the reporter tells me to worry.  Should I do the same thing
> here as well?  When can these tests/reports start to be trusted?

Exactly and no surprise as number of those involved in all of this helped 
get kernelci off the ground. 

Our aim is to have quick summaries either appended with the gory 
details or pointers to it for those that care.

For me the x86 and arm64 results are trustable. We’re working on
getting 4.14-rc runs clean and then we’ll get after the ‘known
errors with 4.4 and 4.9 as well.

32 bit arm results are a bit new/shiny yet.  That’s where I’m most
skeptical when something pops up.

Hope the perspective helps.

> thanks,
> 
> greg k-h

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

> On Oct 21, 2017, at 2:25 AM, Greg Kroah-Hartman  
> wrote:
> 
> On Fri, Oct 20, 2017 at 11:54:38AM -0500, Tom Gall wrote:
>> On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
>>>> fcntl36 and raw_skew we’ll looking into.
>>>> 
>>>> ltp-timers-tests:
>>>>   * leapsec_timer
>>>>   * runltp_timers
>>>> 
>>>>   * test src: git://github.com/linux-test-project/ltp.git
>>>> 
>>>> This one has been working and just failed with this RC cycle. It’s only 
>>>> failing on 32 bit arm.
>>>> 
>>>> Needs to be looked into.
>>> 
>>> When you say "Needs to be looked into", does that mean that you are
>>> pointing this out for someone else to do this (i.e. help, someone look
>>> at this!), or are you going to be working to figure it out?
>> 
>> Help is always great. We've got it covered.
>> 
>> One of the team that works on this board has been looking into it.
>> 
>> As of this second, and looking within the context of 4.4, 4.9 and mainline 
>> data
>> what we're looking at is intermitted failures involving raw_skew from
>> kselftest and leapsec_timer
>> from ltp_timers that is present across all those 3 kernel version and
>> their respective streams.
>> (by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)
>> 
>> As such we can rule these out detecting a regression in the new RC
>> patches. Likely it's board
>> specific.
> 
> Side note, your use of \n is still really odd.  I strongly recommend
> getting a decent email client, or an sane editor that knows what to do
> here….

That email client has been sacked.

> Anyway, if you have board-specific issues, that are not -rc issues, can
> you say so really obviously so I don't worry that I broke something?
> Otherwise it's pretty annoying, as your email implies that I did
> something wrong, and only a few emails in the thread later will it come
> out that this is flaky hardware/tests so there's nothing to worry about.

Reports are pretty new & shiny yet so yes I’m over explaining the logic. 
To me, showing your work applies to other places besides math.

> The kernel.ci reports are a bit like this, I glance at them and only
> worry if the reporter tells me to worry.  Should I do the same thing
> here as well?  When can these tests/reports start to be trusted?

Exactly and no surprise as number of those involved in all of this helped 
get kernelci off the ground. 

Our aim is to have quick summaries either appended with the gory 
details or pointers to it for those that care.

For me the x86 and arm64 results are trustable. We’re working on
getting 4.14-rc runs clean and then we’ll get after the ‘known
errors with 4.4 and 4.9 as well.

32 bit arm results are a bit new/shiny yet.  That’s where I’m most
skeptical when something pops up.

Hope the perspective helps.

> thanks,
> 
> greg k-h

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Thu, Oct 19, 2017 at 05:18:38PM -0500, Tom Gall wrote:
>>
>> > On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman 
>> > <gre...@linuxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.94 release.
>> > There are 46 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 Sat Oct 21 13:48:23 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.94-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 the Linaro test farm. This report is in two parts. The second 
>> part and reported
>> separately is the HiKey results since there are platform support patches 
>> added to the LTS
>> to make it work.
>>
>> Summary
>> 
>>
>> kernel: 4.4.94-rc1
>> git repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> git branch: linux-4.4.y
>> git commit: cc1d76b2d639a37b3e6aec284b6838637d826f08
>> git describe: v4.4.93-47-gcc1d76b2d639
>> Test details: 
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639
>>
>> Regressions (compared to build v4.4.92-29-g51c43ad676c4)
>> 
>>
>> x15 - arm:
>>  kselftest:
>>* raw_skew
>>
>>* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
>>
>>  ltp-syscalls-tests:
>>* fcntl36
>>
>>* test src: git://github.com/linux-test-project/ltp.git
>>
>> fcntl36 and raw_skew we’ll looking into.
>>
>>  ltp-timers-tests:
>>* leapsec_timer
>>* runltp_timers
>>
>>* test src: git://github.com/linux-test-project/ltp.git
>>
>> This one has been working and just failed with this RC cycle. It’s only 
>> failing on 32 bit arm.
>>
>> Needs to be looked into.
>
> When you say "Needs to be looked into", does that mean that you are
> pointing this out for someone else to do this (i.e. help, someone look
> at this!), or are you going to be working to figure it out?

Help is always great. We've got it covered.

One of the team that works on this board has been looking into it.

As of this second, and looking within the context of 4.4, 4.9 and mainline data
what we're looking at is intermitted failures involving raw_skew from
kselftest and leapsec_timer
from ltp_timers that is present across all those 3 kernel version and
their respective streams.
(by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)

As such we can rule these out detecting a regression in the new RC
patches. Likely it's board
specific.

For fcntl36 it's been intermittent only through the series of 4.4
kernels. At the moment we just
have one type of arm 32bit board, so we don't have a history here
where we could refer to and say
fails occasionally on one board but not others. (We'll get there, Rome
wasn't built in a day) At the
time I reported results I couldn't narrow between a board specific
issue, an arch specific issue or
an issue that my have arose due to a bad patch in the RC.

Today however with fcntl36 produced failure for the very first time on
mainline only on X15 which is
a 32 bit arm board.

That should rule out the bad patch scenario in the new RC series.

Having result history you can look back into across multiple versions
and arches is awesome.
Doing all the comparisons, coming at the data from multiple directions
and triple checking to
make sure data is pointing you to reasonable conclusions, that's the fun part.



> thanks,
>
> greg k-h



-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

On Fri, Oct 20, 2017 at 1:26 AM, Greg Kroah-Hartman
 wrote:
> On Thu, Oct 19, 2017 at 05:18:38PM -0500, Tom Gall wrote:
>>
>> > On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman 
>> >  wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.94 release.
>> > There are 46 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 Sat Oct 21 13:48:23 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.94-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 the Linaro test farm. This report is in two parts. The second 
>> part and reported
>> separately is the HiKey results since there are platform support patches 
>> added to the LTS
>> to make it work.
>>
>> Summary
>> 
>>
>> kernel: 4.4.94-rc1
>> git repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> git branch: linux-4.4.y
>> git commit: cc1d76b2d639a37b3e6aec284b6838637d826f08
>> git describe: v4.4.93-47-gcc1d76b2d639
>> Test details: 
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639
>>
>> Regressions (compared to build v4.4.92-29-g51c43ad676c4)
>> 
>>
>> x15 - arm:
>>  kselftest:
>>* raw_skew
>>
>>* test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
>>
>>  ltp-syscalls-tests:
>>* fcntl36
>>
>>* test src: git://github.com/linux-test-project/ltp.git
>>
>> fcntl36 and raw_skew we’ll looking into.
>>
>>  ltp-timers-tests:
>>* leapsec_timer
>>* runltp_timers
>>
>>* test src: git://github.com/linux-test-project/ltp.git
>>
>> This one has been working and just failed with this RC cycle. It’s only 
>> failing on 32 bit arm.
>>
>> Needs to be looked into.
>
> When you say "Needs to be looked into", does that mean that you are
> pointing this out for someone else to do this (i.e. help, someone look
> at this!), or are you going to be working to figure it out?

Help is always great. We've got it covered.

One of the team that works on this board has been looking into it.

As of this second, and looking within the context of 4.4, 4.9 and mainline data
what we're looking at is intermitted failures involving raw_skew from
kselftest and leapsec_timer
from ltp_timers that is present across all those 3 kernel version and
their respective streams.
(by stream I mean FOO, FOO-rc1, FOO+1, FOO+1-rc1, etc)

As such we can rule these out detecting a regression in the new RC
patches. Likely it's board
specific.

For fcntl36 it's been intermittent only through the series of 4.4
kernels. At the moment we just
have one type of arm 32bit board, so we don't have a history here
where we could refer to and say
fails occasionally on one board but not others. (We'll get there, Rome
wasn't built in a day) At the
time I reported results I couldn't narrow between a board specific
issue, an arch specific issue or
an issue that my have arose due to a bad patch in the RC.

Today however with fcntl36 produced failure for the very first time on
mainline only on X15 which is
a 32 bit arm board.

That should rule out the bad patch scenario in the new RC series.

Having result history you can look back into across multiple versions
and arches is awesome.
Doing all the comparisons, coming at the data from multiple directions
and triple checking to
make sure data is pointing you to reasonable conclusions, that's the fun part.



> thanks,
>
> greg k-h



-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/51] 4.9.58-stable review

[Tom Gall]

> On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.58 release.
> There are 51 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 Sat Oct 21 13:48:19 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.9.58-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from the Linaro validation farm.

kernel: 4.9.58-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: f7dffe80de67452121ead836270463be60131376
git describe: v4.9.57-52-gf7dffe80de67
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.57-52-gf7dffe80de67

Regressions (compared to build v4.9.57)


x15 - arm:
 kselftest:
   * raw_skew

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

This has passed as recent as 4.9.57 however it’s also failed as recent as the 
4.6.57-rc cycle. 
We’re looking into it.

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 38, skip: 8, fail: 7 (known failures or in triage)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2 (known failures) 
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 122, fail: 2 (known failures)
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 37, skip: 6, fail: 7 (known and in triage)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, fail: 2 (in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2  (known failures)
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 943, skip: 156, fail: 13 (known failures)
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 36, skip: 1, fail: 16
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known and in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1040, skip: 67, fail: 2 (known failures)
* ltp-timers-tests - pass: 11, fail: 2 (in triage)

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 53, fail: 15 (known and in triage)
* libhugetlbfs - pass: 76, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known and in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 1,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 963, skip: 163, fail: 11 (known failures due to 
NFS)
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/51] 4.9.58-stable review

[Tom Gall]

> On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.58 release.
> There are 51 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 Sat Oct 21 13:48:19 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.9.58-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Results from the Linaro validation farm.

kernel: 4.9.58-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: f7dffe80de67452121ead836270463be60131376
git describe: v4.9.57-52-gf7dffe80de67
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.57-52-gf7dffe80de67

Regressions (compared to build v4.9.57)


x15 - arm:
 kselftest:
   * raw_skew

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

This has passed as recent as 4.9.57 however it’s also failed as recent as the 
4.6.57-rc cycle. 
We’re looking into it.

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 38, skip: 8, fail: 7 (known failures or in triage)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, fail: 2
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2 (known failures) 
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 985, skip: 122, fail: 2 (known failures)
* ltp-timers-tests - pass: 13,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 37, skip: 6, fail: 7 (known and in triage)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 79, fail: 2 (in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2  (known failures)
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 943, skip: 156, fail: 13 (known failures)
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 36, skip: 1, fail: 16
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known and in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1040, skip: 67, fail: 2 (known failures)
* ltp-timers-tests - pass: 11, fail: 2 (in triage)

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 53, fail: 15 (known and in triage)
* libhugetlbfs - pass: 76, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known and in triage)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 1,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 963, skip: 163, fail: 11 (known failures due to 
NFS)
* ltp-timers-tests - pass: 13,



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

> On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.94 release.
> There are 46 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 Sat Oct 21 13:48:23 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.94-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 the Linaro test farm. This report is in two parts. The second part 
and reported 
separately is the HiKey results since there are platform support patches added 
to the LTS
to make it work.

Summary


kernel: 4.4.94-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: cc1d76b2d639a37b3e6aec284b6838637d826f08
git describe: v4.4.93-47-gcc1d76b2d639
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639

Regressions (compared to build v4.4.92-29-g51c43ad676c4)


x15 - arm:
 kselftest:
   * raw_skew

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

 ltp-syscalls-tests:
   * fcntl36

   * test src: git://github.com/linux-test-project/ltp.git

fcntl36 and raw_skew we’ll looking into.

 ltp-timers-tests:
   * leapsec_timer
   * runltp_timers

   * test src: git://github.com/linux-test-project/ltp.git

This one has been working and just failed with this RC cycle. It’s only failing 
on 32 bit arm.

Needs to be looked into.


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 7, fail: 13 (known failures)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, skip: 36, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2 (known failures)
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 938, skip: 159, fail: 15 (known failures)
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 1, fail: 21 (known failures)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 68, fail: 5 (noted above)
* ltp-timers-tests - pass: 11, fail: 2 (noted above)

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 24
* libhugetlbfs - pass: 76, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 960, skip: 164, fail: 13 (known failures)
* ltp-timers-tests - pass: 13,



Summary


kernel: 4.4.94-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.94-rc1-hikey-20171019
git commit: 64eacf43d6ff4c9320737af2fe207e5711010f1f
git describe: 4.4.94-rc1-hikey-20171019
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.94-rc1-hikey-20171019


No regressions (compared to build 4.4.93-rc1-hikey-20171016)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 9, fail: 

Re: [PATCH 4.4 00/46] 4.4.94-stable review

[Tom Gall]

> On Oct 19, 2017, at 8:48 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.94 release.
> There are 46 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 Sat Oct 21 13:48:23 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.94-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 the Linaro test farm. This report is in two parts. The second part 
and reported 
separately is the HiKey results since there are platform support patches added 
to the LTS
to make it work.

Summary


kernel: 4.4.94-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: cc1d76b2d639a37b3e6aec284b6838637d826f08
git describe: v4.4.93-47-gcc1d76b2d639
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.93-47-gcc1d76b2d639

Regressions (compared to build v4.4.92-29-g51c43ad676c4)


x15 - arm:
 kselftest:
   * raw_skew

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz

 ltp-syscalls-tests:
   * fcntl36

   * test src: git://github.com/linux-test-project/ltp.git

fcntl36 and raw_skew we’ll looking into.

 ltp-timers-tests:
   * leapsec_timer
   * runltp_timers

   * test src: git://github.com/linux-test-project/ltp.git

This one has been working and just failed with this RC cycle. It’s only failing 
on 32 bit arm.

Needs to be looked into.


Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 7, fail: 13 (known failures)
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 27, skip: 36, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 59, fail: 2 (known failures)
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 938, skip: 159, fail: 15 (known failures)
* ltp-timers-tests - pass: 13,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 1, fail: 21 (known failures)
* libhugetlbfs - skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 68, fail: 5 (noted above)
* ltp-timers-tests - pass: 11, fail: 2 (noted above)

dell-poweredge-r200 - x86_64
* boot - pass: 20,
* kselftest - pass: 43, fail: 24
* libhugetlbfs - pass: 76, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, fail: 18 (known failures)
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 960, skip: 164, fail: 13 (known failures)
* ltp-timers-tests - pass: 13,



Summary


kernel: 4.4.94-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.94-rc1-hikey-20171019
git commit: 64eacf43d6ff4c9320737af2fe207e5711010f1f
git describe: 4.4.94-rc1-hikey-20171019
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.94-rc1-hikey-20171019


No regressions (compared to build 4.4.93-rc1-hikey-20171016)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 32, skip: 9, fail: 13 (known failures)
* 

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

On Wed, Oct 11, 2017 at 11:47 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Wed, Oct 11, 2017 at 11:12:15AM -0500, Tom Gall wrote:
>> Let’s try that again with less HTML stupidness ….
>>
>> On Oct 11, 2017, at 11:05 AM, Tom Gall <tom.g...@linaro.org> wrote:
>>
>>
>> > On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman 
>> > <gre...@linuxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.92 release.
>> > There are 47 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 Thu Oct 12 19:50:01 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.92-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
>>
>> Full test results from Linaro’s test farm for 4.4.
>>
>> Note there are some further regressions we’ve seen on x15 (arm) beyond the 
>> one I reported
>> last night and that Sumit then commented on.
>>
>> We’ve also moved up to the recently released LTP.
>
> Those two sentances could not possibly be related now, right?  :)

Prior results were just the syscalls portion of LTP. When we expanded to
use all of LTP, that's when we also worked in the upgrade to latest
LTP. LTP isn't changing
that much.

All the non-syscall results data is new. There's a kink or two to work
out there as we get to a
reasonable baseline.

Anything newly reported has been top priority to triage and either get
to working to
put on a skip list and we'll come back to get it working.

> You did test the latest version of LTP on a "known good kernel/system",
> ahead of time?

We're being admittedly aggressive to expand coverage and make
results available. Release early and often.

In the future for anything new, I'll call it out.

> Are these regressions to be expected?

We'll continue to annotate when errors pop up and note if it's
something to be alarmed about.

As I did last night when something looks troubling we're going to
speak up. I'd rather
respond with "here's something" instead of keeping completely silent
and then that turning out
to really be something. You've got a deadline for comments for a reason.

Hard bugs can take time. More eyes helps.

Regardless I want a reasonable clean baseline for at least 4.14 ASAP
and then we get after 4.9 and
4.4.

> x86 doesn't even look right here:
>
>> dell-poweredge-r200 - x86_64
>> * boot - 1 pass
>> * kselftest - 44 pass - 24 known failures
>
> 1/3 failure is ok?

No it's not.

Running kselftest from the current kernel release on an old 4.4 kernel
just isn't going that well.
Tests just don't fail gracefully.  People need to care about that when
they add to ksefltest.

Let's get 4.14 in order first and then get after this stuff.

>> * libhugetlbfs - 76 pass - 1 skip
>> * ltp-cap_bounds-tests - 1 pass
>> * ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test 
>> img)
>> * ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks 
>> like setup issues with veth0)
>> * ltp-fcntl-locktests-tests - 2 pass
>> * ltp-filecaps-tests - 2 pass
>> * ltp-fs-tests - 61 pass - 1 skip
>> * ltp-fs_bind-tests - 2 pass
>> * ltp-fs_perms_simple-tests - 19 pass
>> * ltp-fsx-tests - 2 pass
>> * ltp-hugetlb-tests - 22 pass
>> * ltp-io-tests - 3 pass
>> * ltp-ipc-tests - 9 pass
>> * ltp-math-tests - 11 pass
>> * ltp-nptl-tests - 2 pass
>> * ltp-pty-tests - 4 pass
>> * ltp-sched-tests - 13 pass - 1 skip
>> * ltp-securebits-tests - 4 pass
>> * ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
>
> syscalls fail?  Why skip so many?

The known failures are due to our x86 box using an NFS root file
system. That won't be the case much longer.

As far as skipping, I'll come back with an answer on that. Skipping
isn't always bad if the test isn't really doing
something interesting, or doing something that is going to take way
too long. etc etc. Anyway I'll come back
with something definitive.

> thanks,
>
> greg k-h

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

On Wed, Oct 11, 2017 at 11:47 AM, Greg Kroah-Hartman
 wrote:
> On Wed, Oct 11, 2017 at 11:12:15AM -0500, Tom Gall wrote:
>> Let’s try that again with less HTML stupidness ….
>>
>> On Oct 11, 2017, at 11:05 AM, Tom Gall  wrote:
>>
>>
>> > On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman 
>> >  wrote:
>> >
>> > This is the start of the stable review cycle for the 4.4.92 release.
>> > There are 47 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 Thu Oct 12 19:50:01 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.92-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
>>
>> Full test results from Linaro’s test farm for 4.4.
>>
>> Note there are some further regressions we’ve seen on x15 (arm) beyond the 
>> one I reported
>> last night and that Sumit then commented on.
>>
>> We’ve also moved up to the recently released LTP.
>
> Those two sentances could not possibly be related now, right?  :)

Prior results were just the syscalls portion of LTP. When we expanded to
use all of LTP, that's when we also worked in the upgrade to latest
LTP. LTP isn't changing
that much.

All the non-syscall results data is new. There's a kink or two to work
out there as we get to a
reasonable baseline.

Anything newly reported has been top priority to triage and either get
to working to
put on a skip list and we'll come back to get it working.

> You did test the latest version of LTP on a "known good kernel/system",
> ahead of time?

We're being admittedly aggressive to expand coverage and make
results available. Release early and often.

In the future for anything new, I'll call it out.

> Are these regressions to be expected?

We'll continue to annotate when errors pop up and note if it's
something to be alarmed about.

As I did last night when something looks troubling we're going to
speak up. I'd rather
respond with "here's something" instead of keeping completely silent
and then that turning out
to really be something. You've got a deadline for comments for a reason.

Hard bugs can take time. More eyes helps.

Regardless I want a reasonable clean baseline for at least 4.14 ASAP
and then we get after 4.9 and
4.4.

> x86 doesn't even look right here:
>
>> dell-poweredge-r200 - x86_64
>> * boot - 1 pass
>> * kselftest - 44 pass - 24 known failures
>
> 1/3 failure is ok?

No it's not.

Running kselftest from the current kernel release on an old 4.4 kernel
just isn't going that well.
Tests just don't fail gracefully.  People need to care about that when
they add to ksefltest.

Let's get 4.14 in order first and then get after this stuff.

>> * libhugetlbfs - 76 pass - 1 skip
>> * ltp-cap_bounds-tests - 1 pass
>> * ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test 
>> img)
>> * ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks 
>> like setup issues with veth0)
>> * ltp-fcntl-locktests-tests - 2 pass
>> * ltp-filecaps-tests - 2 pass
>> * ltp-fs-tests - 61 pass - 1 skip
>> * ltp-fs_bind-tests - 2 pass
>> * ltp-fs_perms_simple-tests - 19 pass
>> * ltp-fsx-tests - 2 pass
>> * ltp-hugetlb-tests - 22 pass
>> * ltp-io-tests - 3 pass
>> * ltp-ipc-tests - 9 pass
>> * ltp-math-tests - 11 pass
>> * ltp-nptl-tests - 2 pass
>> * ltp-pty-tests - 4 pass
>> * ltp-sched-tests - 13 pass - 1 skip
>> * ltp-securebits-tests - 4 pass
>> * ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
>
> syscalls fail?  Why skip so many?

The known failures are due to our x86 box using an NFS root file
system. That won't be the case much longer.

As far as skipping, I'll come back with an answer on that. Skipping
isn't always bad if the test isn't really doing
something interesting, or doing something that is going to take way
too long. etc etc. Anyway I'll come back
with something definitive.

> thanks,
>
> greg k-h

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 000/105] 4.9.55-stable review

[Tom Gall]

> On Oct 10, 2017, at 2:49 PM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.55 release.
> There are 105 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 Thu Oct 12 19:24:56 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.9.55-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -

Results from Linaro’s test farm. Juno results are disappointingly unavailable 
and
I’m not willing to hold up this info any longer to wait for it.

kernel: 4.9.55-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 5baa6510b9c929682655869bb2de4c61677dba82
git describe: v4.9.54-106-g5baa6510b9c9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.54-106-g5baa6510b9c9

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 known failures (need ash added to 
test img)
* ltp-containers-tests - 71 pass - 10 known failures (triage in progress, veth0 
needs to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests - 4 pass 
* ltp-syscalls-tests - 985 pass - 122 skip - 2 known failures
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures 
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (need ksh added to 
test img) 
* ltp-containers-tests - 63 pass - 18 fail (being triaged)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 know failures (quota needs to be added to 
the test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 failures (needs to be triaged)
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests  - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1040 pass - 68 skip - 2 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 52 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 15 skip - 5 known failures (need to add ksh to 
test img)
* ltp-containers-tests - 63 pass - 18 failures (triage in progress, veth0 needs 
to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 8 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 963 pass - 163 skip - 11 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 000/105] 4.9.55-stable review

[Tom Gall]

> On Oct 10, 2017, at 2:49 PM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.55 release.
> There are 105 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 Thu Oct 12 19:24:56 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.9.55-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -

Results from Linaro’s test farm. Juno results are disappointingly unavailable 
and
I’m not willing to hold up this info any longer to wait for it.

kernel: 4.9.55-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 5baa6510b9c929682655869bb2de4c61677dba82
git describe: v4.9.54-106-g5baa6510b9c9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.54-106-g5baa6510b9c9

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 known failures (need ash added to 
test img)
* ltp-containers-tests - 71 pass - 10 known failures (triage in progress, veth0 
needs to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests - 4 pass 
* ltp-syscalls-tests - 985 pass - 122 skip - 2 known failures
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures 
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (need ksh added to 
test img) 
* ltp-containers-tests - 63 pass - 18 fail (being triaged)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 know failures (quota needs to be added to 
the test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 failures (needs to be triaged)
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests  - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1040 pass - 68 skip - 2 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64
* boot - 1 pass
* kselftest - 52 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 15 skip - 5 known failures (need to add ksh to 
test img)
* ltp-containers-tests - 63 pass - 18 failures (triage in progress, veth0 needs 
to be setup)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 8 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 963 pass - 163 skip - 11 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

Let’s try that again with less HTML stupidness ….

On Oct 11, 2017, at 11:05 AM, Tom Gall <tom.g...@linaro.org> wrote:


> On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> 
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.92 release.
> There are 47 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 Thu Oct 12 19:50:01 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.92-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

Full test results from Linaro’s test farm for 4.4.

Note there are some further regressions we’ve seen on x15 (arm) beyond the one 
I reported 
last night and that Sumit then commented on.

We’ve also moved up to the recently released LTP.

kernel: 4.4.92-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: c0489dd5896d12b6cc72cde648607f99593f
git describe: v4.4.91-48-gc0489dd5896d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.91-48-gc0489dd5896d

Regressions (compared to build v4.4.91-34-g55c4daf63a48)


x15 - arm:
 kselftest:
   * rtctest

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
 ltp-fs-tests:
   * gf18

   * test src: git://github.com/linux-test-project/ltp.git
 ltp-hugetlb-tests:
   * runltp_hugetlb

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 6 know failures (looks to be 
environmental, need to add ksh to test img)
* ltp-containers-tests - 27 pass - 36 skip - 18 known failures (being looked at 
looks to be setup with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests 
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests -  4 pass
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 31 pass - 1 skip - 21 failures ( regression noted above )
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (ksh not in test 
img)
* ltp-containers-tests - 63 pass - 18 failures (these are being looked at looks 
like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img) - 
regression noted above
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 fail (needs triage) 
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1037 pass - 69 skip - 4 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test 
img) 
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks 
like setup issues with veth0) 
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


Included and kept separate are hikey results (arm64). I keep these separate as 
there are additional 
platform support patches added to the 4.4 LTS in order to make the board work. 


Summary
--

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

Let’s try that again with less HTML stupidness ….

On Oct 11, 2017, at 11:05 AM, Tom Gall  wrote:


> On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.92 release.
> There are 47 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 Thu Oct 12 19:50:01 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.92-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

Full test results from Linaro’s test farm for 4.4.

Note there are some further regressions we’ve seen on x15 (arm) beyond the one 
I reported 
last night and that Sumit then commented on.

We’ve also moved up to the recently released LTP.

kernel: 4.4.92-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: c0489dd5896d12b6cc72cde648607f99593f
git describe: v4.4.91-48-gc0489dd5896d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.91-48-gc0489dd5896d

Regressions (compared to build v4.4.91-34-g55c4daf63a48)


x15 - arm:
 kselftest:
   * rtctest

   * test src: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.13.tar.xz
 ltp-fs-tests:
   * gf18

   * test src: git://github.com/linux-test-project/ltp.git
 ltp-hugetlb-tests:
   * runltp_hugetlb

   * test src: git://github.com/linux-test-project/ltp.git


Boards, architectures and test suites:
-

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 6 know failures (looks to be 
environmental, need to add ksh to test img)
* ltp-containers-tests - 27 pass - 36 skip - 18 known failures (being looked at 
looks to be setup with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img)
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests 
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 14 pass
* ltp-securebits-tests -  4 pass
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 31 pass - 1 skip - 21 failures ( regression noted above )
* libhugetlbfs - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 27 pass - 13 skip - 4 known failures (ksh not in test 
img)
* ltp-containers-tests - 63 pass - 18 failures (these are being looked at looks 
like setup issues with veth0)
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 1 skip - 2 known failures (quota not in test img) - 
regression noted above
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 fail (needs triage) 
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 1037 pass - 69 skip - 4 known failures
* ltp-timers-tests - 13 pass

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 1 pass
* ltp-commands-tests - 27 pass - 13 skip - 5 known failures (ksh not in test 
img) 
* ltp-containers-tests - 63 pass - 18 fail (these are being looked at looks 
like setup issues with veth0) 
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 61 pass - 1 skip
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass - 1 skip
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 960 pass - 164 skip - 13 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


Included and kept separate are hikey results (arm64). I keep these separate as 
there are additional 
platform support patches added to the 4.4 LTS in order to make the board work. 


Summary


kernel: 4.4.92-rc

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

> On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.92 release.
> There are 47 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 Thu Oct 12 19:50:01 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.92-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
> 


On HiKey (arm64) when running ltp-sched with this rc we’re seeing some sort 
of scheduler issue or  maybe some kind of memory corruption.

Raw output of interest : 

https://lkft.validation.linaro.org/scheduler/job/46192#L5291 

ltp-sched-tests__url: git://github.com/linux-test-project/ltp.git
ltp-sched-tests__version: “20170929"
kernel-config: 
http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31/defconfig
build-location: 
http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31

Re: [PATCH 4.4 00/47] 4.4.92-stable review

[Tom Gall]

> On Oct 10, 2017, at 2:50 PM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.92 release.
> There are 47 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 Thu Oct 12 19:50:01 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.92-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
> 


On HiKey (arm64) when running ltp-sched with this rc we’re seeing some sort 
of scheduler issue or  maybe some kind of memory corruption.

Raw output of interest : 

https://lkft.validation.linaro.org/scheduler/job/46192#L5291 

ltp-sched-tests__url: git://github.com/linux-test-project/ltp.git
ltp-sched-tests__version: “20170929"
kernel-config: 
http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31/defconfig
build-location: 
http://snapshots.linaro.org/openembedded/lkft/morty/hikey/rpb/linaro-hikey-stable-rc-4.4/31

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
>> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
>> <gre...@linuxfoundation.org> wrote:
>> >> kernel: 4.9.54-rc1
>> >> git repo: 
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> >> git branch: linux-4.9.y
>> >> git commit: 1852eae92c460813692808234da35d142a405ab7
>> >> git describe: v4.9.53
>> >> Test details: 
>> >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>>
>> >>
>> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>> >
>> > How did your arm64 test build?  There was a build regression in the -rc1
>> > release, are you sure you actually ran the correct image?
>>
>> So the header in that report was wrong. That's a c/n/p error on my
>> part. I was in a rush to get you data before I was going to be gone
>> for the day on Sat and wanting to get what we had into your hands
>> before the Sunday deadline.
>>
>> The test results was for the RC as of commit
>> 0e59436504287cddb9663857ae69c100b55f5e85
>>
>> If you want to see the 'ugly' raw data it's all here :
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
>
> I still don't understand.  That _build_ should have failed, how did it
> succeed enough to actually run the tests at all?

Looks like it's because we don't build with CONFIG_KASAN.

In the case where the build fails, the system won't run tests since there's no
image to run. Likewise if we have a situation where the build fails
for some arches
but not all we'll only get partial test results for the builds that
succeeded and
likewise nothing for what failed.

The results reported were based on commit id
0e59436504287cddb9663857ae69c100b55f5e85

Unfortunately that commit id doesn't exist anymore since it was
replaced by the 4.9.54 release which was commit ID
f37eb7b586f1dd24a86c50278c65322fc6787722

(and yes the release test results == rc test results that were reported)

Things get a little confusing when one can't go back and compare
commit ids. Losing history kinda sucks.

I've thought about some other way to uniquely tie results to an rc
patch maybe working
off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/

But like in this instance if there isn't both the rc1 and rc2 for
posterity it wouldn't help.
Least for now we have commit ids, git describe and kernel version from
the Makefile.

Why wasn't there an rc2 patch file?

> thanks,
>
> greg k-h


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

On Tue, Oct 10, 2017 at 2:11 AM, Greg Kroah-Hartman
 wrote:
> On Mon, Oct 09, 2017 at 03:37:43PM -0500, Tom Gall wrote:
>> On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
>>  wrote:
>> >> kernel: 4.9.54-rc1
>> >> git repo: 
>> >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> >> git branch: linux-4.9.y
>> >> git commit: 1852eae92c460813692808234da35d142a405ab7
>> >> git describe: v4.9.53
>> >> Test details: 
>> >> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53
>>
>> >>
>> >> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>> >
>> > How did your arm64 test build?  There was a build regression in the -rc1
>> > release, are you sure you actually ran the correct image?
>>
>> So the header in that report was wrong. That's a c/n/p error on my
>> part. I was in a rush to get you data before I was going to be gone
>> for the day on Sat and wanting to get what we had into your hands
>> before the Sunday deadline.
>>
>> The test results was for the RC as of commit
>> 0e59436504287cddb9663857ae69c100b55f5e85
>>
>> If you want to see the 'ugly' raw data it's all here :
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/
>
> I still don't understand.  That _build_ should have failed, how did it
> succeed enough to actually run the tests at all?

Looks like it's because we don't build with CONFIG_KASAN.

In the case where the build fails, the system won't run tests since there's no
image to run. Likewise if we have a situation where the build fails
for some arches
but not all we'll only get partial test results for the builds that
succeeded and
likewise nothing for what failed.

The results reported were based on commit id
0e59436504287cddb9663857ae69c100b55f5e85

Unfortunately that commit id doesn't exist anymore since it was
replaced by the 4.9.54 release which was commit ID
f37eb7b586f1dd24a86c50278c65322fc6787722

(and yes the release test results == rc test results that were reported)

Things get a little confusing when one can't go back and compare
commit ids. Losing history kinda sucks.

I've thought about some other way to uniquely tie results to an rc
patch maybe working
off of : https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/

But like in this instance if there isn't both the rc1 and rc2 for
posterity it wouldn't help.
Least for now we have commit ids, git describe and kernel version from
the Makefile.

Why wasn't there an rc2 patch file?

> thanks,
>
> greg k-h


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

Hi Greg,

On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Sat, Oct 07, 2017 at 11:56:17AM -0500, Tom Gall wrote:
>>
>> > On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman 
>> > <gre...@linuxfoundation.org> wrote:
>> >
>> > This is the start of the stable review cycle for the 4.9.54 release.
>> > There are 104 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 Oct  8 08:37:55 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.9.54-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.9.y
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>> From Linaro’s validation farm we have the following test results for this 
>> 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition.  Also this time 
>> around more of LTP is being run. There is triage to do and you’ll notice 
>> that I’m differentiating between ‘known failures’ and ‘failures’ in the data 
>> below. The later obviously will get looked at so we can graduate failures to 
>> known failures/fixes and improve finding regressions. (Anyone want to help?) 
>> In summary I wouldn’t hold up 4.9.54 based on the failures in the new data 
>> below.  Given it’s a Sat, the Mrs has plans, I’ve no time to do further 
>> digging until later.
>
> /me hands Tom some '\n' characters...
>
> :)

w00t!

>> kernel: 4.9.54-rc1
>> git repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> git branch: linux-4.9.y
>> git commit: 1852eae92c460813692808234da35d142a405ab7
>> git describe: v4.9.53
>> Test details: 
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53

>>
>> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>
> How did your arm64 test build?  There was a build regression in the -rc1
> release, are you sure you actually ran the correct image?

So the header in that report was wrong. That's a c/n/p error on my
part. I was in a rush to get you data before I was going to be gone
for the day on Sat and wanting to get what we had into your hands
before the Sunday deadline.

The test results was for the RC as of commit
0e59436504287cddb9663857ae69c100b55f5e85

If you want to see the 'ugly' raw data it's all here :
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/

> Thanks for testing this, finding out the root of these problems this
> week would be great.

We are on it.

> greg k-h

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

Hi Greg,

On Sun, Oct 8, 2017 at 2:23 AM, Greg Kroah-Hartman
 wrote:
> On Sat, Oct 07, 2017 at 11:56:17AM -0500, Tom Gall wrote:
>>
>> > On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman 
>> >  wrote:
>> >
>> > This is the start of the stable review cycle for the 4.9.54 release.
>> > There are 104 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 Oct  8 08:37:55 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.9.54-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.9.y
>> > and the diffstat can be found below.
>> >
>> > thanks,
>> >
>> > greg k-h
>>
>> From Linaro’s validation farm we have the following test results for this 
>> 4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition.  Also this time 
>> around more of LTP is being run. There is triage to do and you’ll notice 
>> that I’m differentiating between ‘known failures’ and ‘failures’ in the data 
>> below. The later obviously will get looked at so we can graduate failures to 
>> known failures/fixes and improve finding regressions. (Anyone want to help?) 
>> In summary I wouldn’t hold up 4.9.54 based on the failures in the new data 
>> below.  Given it’s a Sat, the Mrs has plans, I’ve no time to do further 
>> digging until later.
>
> /me hands Tom some '\n' characters...
>
> :)

w00t!

>> kernel: 4.9.54-rc1
>> git repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> git branch: linux-4.9.y
>> git commit: 1852eae92c460813692808234da35d142a405ab7
>> git describe: v4.9.53
>> Test details: 
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53

>>
>> No regressions (compared to build v4.9.52-65-gaceea42c68d9)
>
> How did your arm64 test build?  There was a build regression in the -rc1
> release, are you sure you actually ran the correct image?

So the header in that report was wrong. That's a c/n/p error on my
part. I was in a rush to get you data before I was going to be gone
for the day on Sat and wanting to get what we had into your hands
before the Sunday deadline.

The test results was for the RC as of commit
0e59436504287cddb9663857ae69c100b55f5e85

If you want to see the 'ugly' raw data it's all here :
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53-105-g0e5943650428/

> Thanks for testing this, finding out the root of these problems this
> week would be great.

We are on it.

> greg k-h

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.4 00/50] 4.4.91-stable review

[Tom Gall]

> On Oct 6, 2017, at 3:52 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.91 release.
> There are 50 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 Oct  8 08:36: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.91-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
> 
> -

From Linaro’s validation farm we have the following test results. TI's 32 bit 
arm board the X15 is a new addition.  More of LTP is being run. There is triage 
to do and you’ll notice that I’m differentiating between ‘known failures’ and 
‘failures’ in the data below. The later obviously will get looked at so we can 
graduate failures to known failures/fixes and improve finding regressions. 
(Anyone want to help?) In summary I wouldn’t hold up 4.4.91 based on the 
failures below, but likewise we shouldn’t get these sit. Given it’s a Sat, the 
Mrs has plans, I’ve no time to dig until later.

kernel: 4.4.91-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 033261bc663341dfd35771aac2eca2614d6921ea
git describe: v4.4.90-51-g033261bc6633
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.90-51-g033261bc6633


No regressions (compared to build v4.4.90)

Boards, architectures and test suites:
-

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 6 fail
* ltp-containers-tests - 27 pass - 36 skip - 18 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 31 pass - 1 skip - 21 fail
* ltp-syscalls-tests - 1018 pass - 80 skip - 2 fail

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures 
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 tests
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

> On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct  8 08:37:55 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.9.54-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

From Linaro’s validation farm we have the following test results for this 
4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition.  Also this time 
around more of LTP is being run. There is triage to do and you’ll notice that 
I’m differentiating between ‘known failures’ and ‘failures’ in the data below. 
The later obviously will get looked at so we can graduate failures to known 
failures/fixes and improve finding regressions. (Anyone want to help?) In 
summary I wouldn’t hold up 4.9.54 based on the failures in the new data below.  
Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until 
later.

kernel: 4.9.54-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 1852eae92c460813692808234da35d142a405ab7
git describe: v4.9.53
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53


No regressions (compared to build v4.9.52-65-gaceea42c68d9)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests 964 pass - 136 skip
* ltp-timers-tests - 13 pass

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass

x15 - arm
* boot - 1 pass
* kselftest - 36 pass - 1 skip - 16 fail 
* ltp-syscalls-tests - 1020 pass - 80 skip

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 53 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests 2 pass
* ltp-filecaps-tests 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 3 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/50] 4.4.91-stable review

[Tom Gall]

> On Oct 6, 2017, at 3:52 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.91 release.
> There are 50 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 Oct  8 08:36: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.91-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
> 
> -

From Linaro’s validation farm we have the following test results. TI's 32 bit 
arm board the X15 is a new addition.  More of LTP is being run. There is triage 
to do and you’ll notice that I’m differentiating between ‘known failures’ and 
‘failures’ in the data below. The later obviously will get looked at so we can 
graduate failures to known failures/fixes and improve finding regressions. 
(Anyone want to help?) In summary I wouldn’t hold up 4.4.91 based on the 
failures below, but likewise we shouldn’t get these sit. Given it’s a Sat, the 
Mrs has plans, I’ve no time to dig until later.

kernel: 4.4.91-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 033261bc663341dfd35771aac2eca2614d6921ea
git describe: v4.4.90-51-g033261bc6633
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.90-51-g033261bc6633


No regressions (compared to build v4.4.90)

Boards, architectures and test suites:
-

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 6 fail
* ltp-containers-tests - 27 pass - 36 skip - 18 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-timers-tests - 13 pass

x15 - arm 
* boot - 1 pass
* kselftest - 31 pass - 1 skip - 21 fail
* ltp-syscalls-tests - 1018 pass - 80 skip - 2 fail

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures 
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 tests
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 000/104] 4.9.54-stable review

[Tom Gall]

> On Oct 6, 2017, at 3:50 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.54 release.
> There are 104 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 Oct  8 08:37:55 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.9.54-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

From Linaro’s validation farm we have the following test results for this 
4.9.54-rc1. TI's 32 bit arm board the X15 is a new addition.  Also this time 
around more of LTP is being run. There is triage to do and you’ll notice that 
I’m differentiating between ‘known failures’ and ‘failures’ in the data below. 
The later obviously will get looked at so we can graduate failures to known 
failures/fixes and improve finding regressions. (Anyone want to help?) In 
summary I wouldn’t hold up 4.9.54 based on the failures in the new data below.  
Given it’s a Sat, the Mrs has plans, I’ve no time to do further digging until 
later.

kernel: 4.9.54-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 1852eae92c460813692808234da35d142a405ab7
git describe: v4.9.53
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.53


No regressions (compared to build v4.9.52-65-gaceea42c68d9)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 25 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 21 pass - 1 skip
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 4 pass
* ltp-syscalls-tests 964 pass - 136 skip
* ltp-timers-tests - 13 pass

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-cap_bounds-tests - 2 pass
* ltp-commands-tests - 26 pass - 13 skip - 5 fail
* ltp-containers-tests - 71 pass - 10 fail
* ltp-fcntl-locktests-tests - 2 pass
* ltp-filecaps-tests - 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass

x15 - arm
* boot - 1 pass
* kselftest - 36 pass - 1 skip - 16 fail 
* ltp-syscalls-tests - 1020 pass - 80 skip

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 53 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-cap_bounds-tests 2 pass
* ltp-commands-tests - 23 pass - 13 skip - 8 fail
* ltp-containers-tests - 63 pass - 18 fail
* ltp-fcntl-locktests-tests 2 pass
* ltp-filecaps-tests 2 pass
* ltp-fs-tests - 59 pass - 3 fail
* ltp-fs_bind-tests - 2 pass
* ltp-fs_perms_simple-tests - 19 pass
* ltp-fsx-tests - 2 pass
* ltp-hugetlb-tests - 22 pass
* ltp-io-tests - 3 pass
* ltp-ipc-tests - 9 pass
* ltp-math-tests - 11 pass
* ltp-nptl-tests - 2 pass
* ltp-pty-tests - 4 pass
* ltp-sched-tests - 13 pass
* ltp-securebits-tests - 3 pass
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures
* ltp-timers-tests - 13 pass



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.4 00/41] 4.4.90-stable review

[Tom Gall]

> On Oct 3, 2017, at 7:21 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.90 release.
> There are 41 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 Thu Oct  5 11:42:00 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.90-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
> 

Test results from the linaro linux kernel functional test farm:

kernel: 4.4.90-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 255b4a073a820d2f46a1ce1740f1a9be3de9661a
git describe: v4.4.89-42-g255b4a073a82
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.89-42-g255b4a073a82

No regressions (compared to build v4.4.89-30-gb547584d016b)

Boards, architectures and test suites:
-

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures 


And as a separate but related report, we have HiKey (arm64) results. These are 
separate because there are some out of tree patches that didn’t quite make 4.4 
back in the day, thus for this board the kernel is a blend of the LTS RC + some 
platform patches.

Summary


kernel: 4.4.90-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.90-rc1-hikey-20171003
git commit: 8b0848771d885b6030233931b2d2039382a1cf73
git describe: v4.4.89-352-g8b0848771d88
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/v4.4.89-352-g8b0848771d88


No regressions (compared to build v4.4.89-340-ga6279f8aa398)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-syscalls-tests - 960 pass - 138 skip - 2 known failures

Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall  

"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" 
Marvin Martian

Re: [PATCH 4.4 00/41] 4.4.90-stable review

[Tom Gall]

> On Oct 3, 2017, at 7:21 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.4.90 release.
> There are 41 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 Thu Oct  5 11:42:00 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.90-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
> 

Test results from the linaro linux kernel functional test farm:

kernel: 4.4.90-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 255b4a073a820d2f46a1ce1740f1a9be3de9661a
git describe: v4.4.89-42-g255b4a073a82
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.89-42-g255b4a073a82

No regressions (compared to build v4.4.89-30-gb547584d016b)

Boards, architectures and test suites:
-

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 44 pass - 24 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-syscalls-tests - 941 pass - 175 skip - 11 known failures 


And as a separate but related report, we have HiKey (arm64) results. These are 
separate because there are some out of tree patches that didn’t quite make 4.4 
back in the day, thus for this board the kernel is a blend of the LTS RC + some 
platform patches.

Summary


kernel: 4.4.90-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.90-rc1-hikey-20171003
git commit: 8b0848771d885b6030233931b2d2039382a1cf73
git describe: v4.4.89-352-g8b0848771d88
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/v4.4.89-352-g8b0848771d88


No regressions (compared to build v4.4.89-340-ga6279f8aa398)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 32 pass - 1 skip - 21 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-syscalls-tests - 960 pass - 138 skip - 2 known failures

Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall  

"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" 
Marvin Martian

Re: [PATCH 4.9 00/64] 4.9.53-stable review

[Tom Gall]

> On Oct 3, 2017, at 7:22 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.53 release.
> There are 64 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 Thu Oct  5 11:42:06 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.9.53-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 


Test results from the linaro linux kernel functional test farm:

kernel: 4.9.53-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: aceea42c68d96c58958954e4c8c23a26f8883d62
git describe: v4.9.52-65-gaceea42c68d9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.52-65-gaceea42c68d9


No regressions (compared to build v4.9.51-78-ge009129d09cb)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-syscalls-tests - 964 pass - 136 skip

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 14 known failures
* libhugetlbfs - 90 pass - 1 skip

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 52 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-syscalls-tests - 941 pass - 175 skip - 11known failures

Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall  

"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" 
Marvin Martian

Re: [PATCH 4.9 00/64] 4.9.53-stable review

[Tom Gall]

> On Oct 3, 2017, at 7:22 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.53 release.
> There are 64 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 Thu Oct  5 11:42:06 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.9.53-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 


Test results from the linaro linux kernel functional test farm:

kernel: 4.9.53-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: aceea42c68d96c58958954e4c8c23a26f8883d62
git describe: v4.9.52-65-gaceea42c68d9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.52-65-gaceea42c68d9


No regressions (compared to build v4.9.51-78-ge009129d09cb)

Boards, architectures and test suites:
-

hi6220-hikey - arm64 
* boot - 1 pass
* kselftest - 38 pass - 1 skip - 15 known failures
* libhugetlbfs - 90 pass - 1 skip
* ltp-syscalls-tests - 964 pass - 136 skip

juno-r2 - arm64 
* boot - 1 pass
* kselftest - 37 pass - 1 skip - 14 known failures
* libhugetlbfs - 90 pass - 1 skip

dell-poweredge-r200 - x86_64 
* boot - 1 pass
* kselftest - 52 pass - 15 known failures
* libhugetlbfs - 76 pass - 1 skip
* ltp-syscalls-tests - 941 pass - 175 skip - 11known failures

Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall  

"Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" 
Marvin Martian

Re: [PATCH 4.9 00/77] 4.9.52-stable review

[Tom Gall]

On Sun, Sep 24, 2017 at 3:31 PM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.52 release.
> There are 77 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 Tue Sep 26 20:32:25 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.9.52-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

kernel: 4.9.52-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: e009129d09cb626ff5271c9de006883671f38ab3
git describe: v4.9.51-78-ge009129d09cb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.51-78-ge009129d09cb


No regressions (compared to build v4.9.51)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot
* libhugetlbfs
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* boot
* kselftest
* libhugetlbfs
* ltp-syscalls-tests



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/77] 4.9.52-stable review

[Tom Gall]

On Sun, Sep 24, 2017 at 3:31 PM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.52 release.
> There are 77 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 Tue Sep 26 20:32:25 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.9.52-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

kernel: 4.9.52-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: e009129d09cb626ff5271c9de006883671f38ab3
git describe: v4.9.51-78-ge009129d09cb
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.51-78-ge009129d09cb


No regressions (compared to build v4.9.51)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot
* libhugetlbfs
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* boot
* kselftest
* libhugetlbfs
* ltp-syscalls-tests



Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/78] 4.9.51-stable review

[Tom Gall]

On Mon, Sep 18, 2017 at 4:11 AM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.51 release.
> There are 78 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 Wed Sep 20 09:10:51 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.9.51-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from testing on Linaro's little test farm.

Summary


kernel: 4.9.51-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8d96ea41a3ee57a7a145054e57fe0fb1a5d19861
git describe: v4.9.50-79-g8d96ea41a3ee
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.50-79-g8d96ea41a3ee


No regressions (compared to build v4.9.50)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* libhugetlbfs
* kselftest
* boot
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* kselftest
* libhugetlbfs
* boot
* ltp-syscalls-tests


Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/78] 4.9.51-stable review

[Tom Gall]

On Mon, Sep 18, 2017 at 4:11 AM, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.51 release.
> There are 78 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 Wed Sep 20 09:10:51 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.9.51-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.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from testing on Linaro's little test farm.

Summary


kernel: 4.9.51-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 8d96ea41a3ee57a7a145054e57fe0fb1a5d19861
git describe: v4.9.50-79-g8d96ea41a3ee
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.50-79-g8d96ea41a3ee


No regressions (compared to build v4.9.50)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* libhugetlbfs
* kselftest
* boot
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* kselftest
* libhugetlbfs
* boot
* ltp-syscalls-tests


Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports


-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
>>
>> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman 
>> > <gre...@linuxfoundation.org> wrote:

>>
>> Results from testing on Linaro’s small but growing test farm.
>>
>> 
>> Summary
>> 
>>
>> kernel: 4.9.50-rc1
>> kernel-repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> kernel-branch: linux-4.9.y
>> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
>> kernel-describe: v4.9.49-15-gedfaa5f69b96
>
> Howcome 'git describe' does not show 4.9.50-rc1?

git describe looks for the most recent tag.

Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc.

Does it make sense to create tags for the RC(s) so git describe gets
it right? Given the right version is in the Makefile kinda feels like
that'd be a belt and suspenders approach.






-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman
 wrote:
> On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
>>
>> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman 
>> >  wrote:

>>
>> Results from testing on Linaro’s small but growing test farm.
>>
>> 
>> Summary
>> 
>>
>> kernel: 4.9.50-rc1
>> kernel-repo: 
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> kernel-branch: linux-4.9.y
>> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
>> kernel-describe: v4.9.49-15-gedfaa5f69b96
>
> Howcome 'git describe' does not show 4.9.50-rc1?

git describe looks for the most recent tag.

Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc.

Does it make sense to create tags for the RC(s) so git describe gets
it right? Given the right version is in the Makefile kinda feels like
that'd be a belt and suspenders approach.






-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

> On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.50 release.
> There are 14 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 Thu Sep 14 16:52:45 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.9.50-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Results from testing on Linaro’s small but growing test farm. 


Summary


kernel: 4.9.50-rc1
kernel-repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
kernel-branch: linux-4.9.y
kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
kernel-describe: v4.9.49-15-gedfaa5f69b96
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.49-15-gedfaa5f69b96


No regressions (compared to build v4.9.49)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* libhugetlbfs
* kselftest
* boot
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* kselftest
* libhugetlbfs
* boot
* ltp-syscalls-tests

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

> On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman  
> wrote:
> 
> This is the start of the stable review cycle for the 4.9.50 release.
> There are 14 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 Thu Sep 14 16:52:45 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.9.50-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.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Results from testing on Linaro’s small but growing test farm. 


Summary


kernel: 4.9.50-rc1
kernel-repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
kernel-branch: linux-4.9.y
kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
kernel-describe: v4.9.49-15-gedfaa5f69b96
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.49-15-gedfaa5f69b96


No regressions (compared to build v4.9.49)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* libhugetlbfs
* kselftest
* boot
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* kselftest
* libhugetlbfs
* boot
* ltp-syscalls-tests

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Tom Gall]

Hi Shuah,

On Fri, Jun 23, 2017 at 2:03 PM, Shuah Khan <sh...@kernel.org> wrote:
> On 06/22/2017 01:48 PM, Tom Gall wrote:
>> Hi
>>
>> On Thu, Jun 22, 2017 at 2:06 PM, Shuah Khan <sh...@kernel.org> wrote:
>>> On 06/22/2017 11:50 AM, Kees Cook wrote:
>>>> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski <l...@kernel.org> wrote:
>>>>> On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan <sh...@kernel.org> wrote:
>>>>>> On 06/22/2017 10:53 AM, Kees Cook wrote:
>>>>>>> On Thu, Jun 22, 2017 at 9:18 AM, Sumit Semwal <sumit.sem...@linaro.org> 
>>>>>>> wrote:
>>>>>>>> Hi Kees, Andy,
>>>>>>>>
>>>>>>>> On 15 June 2017 at 23:26, Sumit Semwal <sumit.sem...@linaro.org> wrote:
>>>>>>>>> 3. 'seccomp ptrace hole closure' patches got added in 4.7 [3] -
>>>>>>>>> feature and test together.
>>>>>>>>> - This one also seems like a security hole being closed, and the
>>>>>>>>> 'feature' could be a candidate for stable backports, but Arnd tried
>>>>>>>>> that, and it was quite non-trivial. So perhaps  we'll need some help
>>>>>>>>> from the subsystem developers here.
>>>>>>>>
>>>>>>>> Could you please help us sort this out? Our goal is to help Greg with
>>>>>>>> testing stable kernels, and currently the seccomp tests fail due to
>>>>>>>> missing feature (seccomp ptrace hole closure) getting tested via
>>>>>>>> latest kselftest.
>>>>>>>>
>>>>>>>> If you feel the feature isn't a stable candidate, then could you
>>>>>>>> please help make the test degrade gracefully in its absence?
>>>
>>> In some cases, it is not easy to degrade and/or check for a feature.
>>> Probably several security features could fall in this bucket.
>>>
>>>>>>>
>>>>>>> I don't really want to have that change be a backport -- it's quite
>>>>>>> invasive across multiple architectures.
>>>
>>> Agreed. The same test for kernel applies to tests as well. If a kernel
>>> feature can't be back-ported, the test for that feature will fall in the
>>> same bucket. It shouldn't be back-ported.
>>>
>>>>>>>
>>>>>>> I would say just add a kernel version check to the test. This is
>>>>>>> probably not the only selftest that will need such things. :)
>>>>>>
>>>>>> Adding release checks to selftests is going to problematic for 
>>>>>> maintenance.
>>>>>> Tests should fail gracefully if feature isn't supported in older kernels.
>>>>>>
>>>>>> Several tests do that now and please find a way to check for dependencies
>>>>>> and feature availability and fail the test gracefully. If there is a test
>>>>>> that can't do that for some reason, we can discuss it, but as a general
>>>>>> rule, I don't want to see kselftest patches that check release.
>>>>>
>>>>> If a future kernel inadvertently loses the new feature and degrades to
>>>>> the behavior of old kernels, that would be a serious bug and should be
>>>>> caught.
>>>
>>> Agreed. If I understand you correctly, by not testing stable kernels
>>> with their own selftests, some serious bugs could go undetected.
>>
>> Personally I'm a bit skeptical. I think the reasoning is more that the
>> latest selftests provide more coverage, and therefore should be better
>> tests, even on older kernels.
>>
>>>>
>>>> Right. I really think stable kernels should be tested with their own
>>>> selftests. If some test is needed in a stable kernel it should be
>>>> backported to that stable kernel.
>>>
>>> Correct. This is always a safe option. There might be cases that even
>>> prevent tests being built, especially if a new feature adds new fields
>>> to an existing structure.
>>>
>>> It appears in some cases, users want to run newer tests on older kernels.
>>> Some tests can clearly detect feature support using module presence and/or
>>> Kconfig enabled or disabled. These are conditions even on a kernel that
>>> supports a new module or new config option. The kernel the test is running

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Tom Gall]

Hi Shuah,

On Fri, Jun 23, 2017 at 2:03 PM, Shuah Khan  wrote:
> On 06/22/2017 01:48 PM, Tom Gall wrote:
>> Hi
>>
>> On Thu, Jun 22, 2017 at 2:06 PM, Shuah Khan  wrote:
>>> On 06/22/2017 11:50 AM, Kees Cook wrote:
>>>> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski  wrote:
>>>>> On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan  wrote:
>>>>>> On 06/22/2017 10:53 AM, Kees Cook wrote:
>>>>>>> On Thu, Jun 22, 2017 at 9:18 AM, Sumit Semwal  
>>>>>>> wrote:
>>>>>>>> Hi Kees, Andy,
>>>>>>>>
>>>>>>>> On 15 June 2017 at 23:26, Sumit Semwal  wrote:
>>>>>>>>> 3. 'seccomp ptrace hole closure' patches got added in 4.7 [3] -
>>>>>>>>> feature and test together.
>>>>>>>>> - This one also seems like a security hole being closed, and the
>>>>>>>>> 'feature' could be a candidate for stable backports, but Arnd tried
>>>>>>>>> that, and it was quite non-trivial. So perhaps  we'll need some help
>>>>>>>>> from the subsystem developers here.
>>>>>>>>
>>>>>>>> Could you please help us sort this out? Our goal is to help Greg with
>>>>>>>> testing stable kernels, and currently the seccomp tests fail due to
>>>>>>>> missing feature (seccomp ptrace hole closure) getting tested via
>>>>>>>> latest kselftest.
>>>>>>>>
>>>>>>>> If you feel the feature isn't a stable candidate, then could you
>>>>>>>> please help make the test degrade gracefully in its absence?
>>>
>>> In some cases, it is not easy to degrade and/or check for a feature.
>>> Probably several security features could fall in this bucket.
>>>
>>>>>>>
>>>>>>> I don't really want to have that change be a backport -- it's quite
>>>>>>> invasive across multiple architectures.
>>>
>>> Agreed. The same test for kernel applies to tests as well. If a kernel
>>> feature can't be back-ported, the test for that feature will fall in the
>>> same bucket. It shouldn't be back-ported.
>>>
>>>>>>>
>>>>>>> I would say just add a kernel version check to the test. This is
>>>>>>> probably not the only selftest that will need such things. :)
>>>>>>
>>>>>> Adding release checks to selftests is going to problematic for 
>>>>>> maintenance.
>>>>>> Tests should fail gracefully if feature isn't supported in older kernels.
>>>>>>
>>>>>> Several tests do that now and please find a way to check for dependencies
>>>>>> and feature availability and fail the test gracefully. If there is a test
>>>>>> that can't do that for some reason, we can discuss it, but as a general
>>>>>> rule, I don't want to see kselftest patches that check release.
>>>>>
>>>>> If a future kernel inadvertently loses the new feature and degrades to
>>>>> the behavior of old kernels, that would be a serious bug and should be
>>>>> caught.
>>>
>>> Agreed. If I understand you correctly, by not testing stable kernels
>>> with their own selftests, some serious bugs could go undetected.
>>
>> Personally I'm a bit skeptical. I think the reasoning is more that the
>> latest selftests provide more coverage, and therefore should be better
>> tests, even on older kernels.
>>
>>>>
>>>> Right. I really think stable kernels should be tested with their own
>>>> selftests. If some test is needed in a stable kernel it should be
>>>> backported to that stable kernel.
>>>
>>> Correct. This is always a safe option. There might be cases that even
>>> prevent tests being built, especially if a new feature adds new fields
>>> to an existing structure.
>>>
>>> It appears in some cases, users want to run newer tests on older kernels.
>>> Some tests can clearly detect feature support using module presence and/or
>>> Kconfig enabled or disabled. These are conditions even on a kernel that
>>> supports a new module or new config option. The kernel the test is running
>>> on might not have the feature enabled or module might not be present. In
>>> these cases, it would be easier to detect and sk

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Tom Gall]

Hi

On Thu, Jun 22, 2017 at 2:06 PM, Shuah Khan  wrote:
> On 06/22/2017 11:50 AM, Kees Cook wrote:
>> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski  wrote:
>>> On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan  wrote:
 On 06/22/2017 10:53 AM, Kees Cook wrote:
> On Thu, Jun 22, 2017 at 9:18 AM, Sumit Semwal  
> wrote:
>> Hi Kees, Andy,
>>
>> On 15 June 2017 at 23:26, Sumit Semwal  wrote:
>>> 3. 'seccomp ptrace hole closure' patches got added in 4.7 [3] -
>>> feature and test together.
>>> - This one also seems like a security hole being closed, and the
>>> 'feature' could be a candidate for stable backports, but Arnd tried
>>> that, and it was quite non-trivial. So perhaps  we'll need some help
>>> from the subsystem developers here.
>>
>> Could you please help us sort this out? Our goal is to help Greg with
>> testing stable kernels, and currently the seccomp tests fail due to
>> missing feature (seccomp ptrace hole closure) getting tested via
>> latest kselftest.
>>
>> If you feel the feature isn't a stable candidate, then could you
>> please help make the test degrade gracefully in its absence?
>
> In some cases, it is not easy to degrade and/or check for a feature.
> Probably several security features could fall in this bucket.
>
>
> I don't really want to have that change be a backport -- it's quite
> invasive across multiple architectures.
>
> Agreed. The same test for kernel applies to tests as well. If a kernel
> feature can't be back-ported, the test for that feature will fall in the
> same bucket. It shouldn't be back-ported.
>
>
> I would say just add a kernel version check to the test. This is
> probably not the only selftest that will need such things. :)

 Adding release checks to selftests is going to problematic for maintenance.
 Tests should fail gracefully if feature isn't supported in older kernels.

 Several tests do that now and please find a way to check for dependencies
 and feature availability and fail the test gracefully. If there is a test
 that can't do that for some reason, we can discuss it, but as a general
 rule, I don't want to see kselftest patches that check release.
>>>
>>> If a future kernel inadvertently loses the new feature and degrades to
>>> the behavior of old kernels, that would be a serious bug and should be
>>> caught.
>
> Agreed. If I understand you correctly, by not testing stable kernels
> with their own selftests, some serious bugs could go undetected.

Personally I'm a bit skeptical. I think the reasoning is more that the
latest selftests provide more coverage, and therefore should be better
tests, even on older kernels.

>>
>> Right. I really think stable kernels should be tested with their own
>> selftests. If some test is needed in a stable kernel it should be
>> backported to that stable kernel.
>
> Correct. This is always a safe option. There might be cases that even
> prevent tests being built, especially if a new feature adds new fields
> to an existing structure.
>
> It appears in some cases, users want to run newer tests on older kernels.
> Some tests can clearly detect feature support using module presence and/or
> Kconfig enabled or disabled. These are conditions even on a kernel that
> supports a new module or new config option. The kernel the test is running
> on might not have the feature enabled or module might not be present. In
> these cases, it would be easier to detect and skip the test.
>
> However, some features aren't so easy. For example:
>
> - a new flag is added to a syscall, and new test is added. It might not
>   be easy to detect that.
> - We might have some tests that can't detect and skip.
>
> Based on this discussion, it is probably accurate to say:
>
> 1. It is recommended that selftests from the same release be run on the
>kernel.
> 2. Selftests from newer kernels will run on older kernels, user should
>understand the risks such as some tests might fail and might not
>detect feature degradation related bugs.
> 3. Selftests will fail gracefully on older releases if at all possible.

How about gracefully be skipped instead of fail?

The later suggests the test case in some situations can detect it's
pointless to run something and say as much instead of emitting a
failure that would be a waste of time to look into.

As another example take tools/testing/selftests/net/psock_fanout.c
On 4.9 it'll fail to compile (using master's selftests) because
PACKET_FANOUT_FLAG_UNIQUEID isn't defined. Add a simple #ifdef for
that symbol and the psock_fanout test will compile and run just fine.

> Sumit!
>
> 1. What are the reasons for testing older kernel with selftests from
>newer kernels? What are the benefits you see for doing so?

I think the presumption is the latest greatest collection 

Re: seccomp ptrace selftest failures with 4.4-stable [Was: Re: LTS testing with latest kselftests - some failures]

[Tom Gall]

Hi

On Thu, Jun 22, 2017 at 2:06 PM, Shuah Khan  wrote:
> On 06/22/2017 11:50 AM, Kees Cook wrote:
>> On Thu, Jun 22, 2017 at 10:49 AM, Andy Lutomirski  wrote:
>>> On Thu, Jun 22, 2017 at 10:09 AM, Shuah Khan  wrote:
 On 06/22/2017 10:53 AM, Kees Cook wrote:
> On Thu, Jun 22, 2017 at 9:18 AM, Sumit Semwal  
> wrote:
>> Hi Kees, Andy,
>>
>> On 15 June 2017 at 23:26, Sumit Semwal  wrote:
>>> 3. 'seccomp ptrace hole closure' patches got added in 4.7 [3] -
>>> feature and test together.
>>> - This one also seems like a security hole being closed, and the
>>> 'feature' could be a candidate for stable backports, but Arnd tried
>>> that, and it was quite non-trivial. So perhaps  we'll need some help
>>> from the subsystem developers here.
>>
>> Could you please help us sort this out? Our goal is to help Greg with
>> testing stable kernels, and currently the seccomp tests fail due to
>> missing feature (seccomp ptrace hole closure) getting tested via
>> latest kselftest.
>>
>> If you feel the feature isn't a stable candidate, then could you
>> please help make the test degrade gracefully in its absence?
>
> In some cases, it is not easy to degrade and/or check for a feature.
> Probably several security features could fall in this bucket.
>
>
> I don't really want to have that change be a backport -- it's quite
> invasive across multiple architectures.
>
> Agreed. The same test for kernel applies to tests as well. If a kernel
> feature can't be back-ported, the test for that feature will fall in the
> same bucket. It shouldn't be back-ported.
>
>
> I would say just add a kernel version check to the test. This is
> probably not the only selftest that will need such things. :)

 Adding release checks to selftests is going to problematic for maintenance.
 Tests should fail gracefully if feature isn't supported in older kernels.

 Several tests do that now and please find a way to check for dependencies
 and feature availability and fail the test gracefully. If there is a test
 that can't do that for some reason, we can discuss it, but as a general
 rule, I don't want to see kselftest patches that check release.
>>>
>>> If a future kernel inadvertently loses the new feature and degrades to
>>> the behavior of old kernels, that would be a serious bug and should be
>>> caught.
>
> Agreed. If I understand you correctly, by not testing stable kernels
> with their own selftests, some serious bugs could go undetected.

Personally I'm a bit skeptical. I think the reasoning is more that the
latest selftests provide more coverage, and therefore should be better
tests, even on older kernels.

>>
>> Right. I really think stable kernels should be tested with their own
>> selftests. If some test is needed in a stable kernel it should be
>> backported to that stable kernel.
>
> Correct. This is always a safe option. There might be cases that even
> prevent tests being built, especially if a new feature adds new fields
> to an existing structure.
>
> It appears in some cases, users want to run newer tests on older kernels.
> Some tests can clearly detect feature support using module presence and/or
> Kconfig enabled or disabled. These are conditions even on a kernel that
> supports a new module or new config option. The kernel the test is running
> on might not have the feature enabled or module might not be present. In
> these cases, it would be easier to detect and skip the test.
>
> However, some features aren't so easy. For example:
>
> - a new flag is added to a syscall, and new test is added. It might not
>   be easy to detect that.
> - We might have some tests that can't detect and skip.
>
> Based on this discussion, it is probably accurate to say:
>
> 1. It is recommended that selftests from the same release be run on the
>kernel.
> 2. Selftests from newer kernels will run on older kernels, user should
>understand the risks such as some tests might fail and might not
>detect feature degradation related bugs.
> 3. Selftests will fail gracefully on older releases if at all possible.

How about gracefully be skipped instead of fail?

The later suggests the test case in some situations can detect it's
pointless to run something and say as much instead of emitting a
failure that would be a waste of time to look into.

As another example take tools/testing/selftests/net/psock_fanout.c
On 4.9 it'll fail to compile (using master's selftests) because
PACKET_FANOUT_FLAG_UNIQUEID isn't defined. Add a simple #ifdef for
that symbol and the psock_fanout test will compile and run just fine.

> Sumit!
>
> 1. What are the reasons for testing older kernel with selftests from
>newer kernels? What are the benefits you see for doing so?

I think the presumption is the latest greatest collection of selftests
are the best, most complete.

>I am looking to understand the need/reasons for this 

kselftest backports?

[Tom Gall]

We've been running kselftests for ARM and x86 hardware in an effort to
detect regressions in various kernels including LTS and candidate
patches.

One general question we've had is what's the right thing to do when it
comes to running kselftest on older LTS kernels. Let's pick on 4.4 for
the purposes of this discussion tho obviously the example applies to
other versions.

1) Run current top of tree, kselftest on a 4.4 LTS?
2) Run kselftest from 4.4 on 4.4 LTS?

#1 gets latest greatest set of tests but obviously there can be
breakage because of how the kernel evolves over time.
#2 misses tests that are later developed but otherwise fine

Regardless of the right answer, some obvious questions but I'll ask anyway:
-) Shouldn't new additions to kselftest that work on older kernels be
backported and submitted on the stable list?
-) In the case where some test is kernel version specific for whatever
reason, I presume building in version detection into kselftest makes
sense?

Thanks.

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | @tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

kselftest backports?

[Tom Gall]

We've been running kselftests for ARM and x86 hardware in an effort to
detect regressions in various kernels including LTS and candidate
patches.

One general question we've had is what's the right thing to do when it
comes to running kselftest on older LTS kernels. Let's pick on 4.4 for
the purposes of this discussion tho obviously the example applies to
other versions.

1) Run current top of tree, kselftest on a 4.4 LTS?
2) Run kselftest from 4.4 on 4.4 LTS?

#1 gets latest greatest set of tests but obviously there can be
breakage because of how the kernel evolves over time.
#2 misses tests that are later developed but otherwise fine

Regardless of the right answer, some obvious questions but I'll ask anyway:
-) Shouldn't new additions to kselftest that work on older kernels be
backported and submitted on the stable list?
-) In the case where some test is kernel version specific for whatever
reason, I presume building in version detection into kselftest makes
sense?

Thanks.

-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | @tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: runaway loop modprobe binfmt-0000

[Tom Gall]

Hi Andrew,

Thanks for the email back.

Andrew Morton wrote:


On Thu, 03 Jan 2008 12:18:19 -0600 Tom Gall <[EMAIL PROTECTED]> wrote:
 

This is an interesting one as I just hit this with a 2.6.23.12 kernel 
...  granted running on systemsim (the powerpc simulator) ... but as I'm 
hitting a wall I dropped in the dump_stack call and here is the output:
   



I don't remember what any of this is about and there is no record on the
mailing list - presumably because you're ccing [EMAIL PROTECTED] and not
[EMAIL PROTECTED]
 

Ever written the previous year on your checks? Well when I was googling 
about for folks with similar woes, the posts I had thought were from 
this January were actually from Jan 2007.  O Well! Not to mention it's 
been awhile since I've posted to lkml 


I suggest that we start again with this bug report from scratch.  
 

In this case, not needed. I spent friday taking a tour of the codepath 
and basically narrowed it down to a device driver passing bum data.


So if this ever happens in the future and someone somewhere seems the 
message about trying to load binfmt- (where  is  or some 
other "random" number * (hold that thought I'll come back to this) ) 
here are some things to consider as you're debugging your problem.


In my case, the device driver was just good enough that it could access 
the device, but was poor enough that the bits it was loading were 
complete crap ...   So the kernel was happily running along booting, 
gets to the point where it's time to exec init, loads the first bits of 
the binary, does a compare to make sure it's an elf binary, fails the 
compare (because the data is junk) ...  the kernel figures that ooo .. 
this data must be good it's just in a different format ... I'll run 
through the list of known binary file formats.. hmm not that one .. or 
that one    then running out of options trys to load a module for 
what must be this amazing new file format, can't find the module and 
ker-blew-ee.


* So this number that is part of the module name binfmt- is from 
what I see the id of the file format ... thankfully no one has choosen 
 as their id ...



Unless it's a potential denial-of-service attack for unprivileged users,
in which case a cc to [EMAIL PROTECTED] migt be more appropriate.
 

As this is a boot time issue it's certainly not a DOS.  Now there might 
be value is thinking about this error path in the initial boot up of the 
kernel. The message is a bit obscure for what the real issue is. Still 
.. should one go back to the device and comfirm that the data received 
was actually reasonable? No.


So I think we have two cases here:

Bootup:
I could see a change where the system should probably panic with some 
sort of message like : "Not able to exec %s, unrecognized file format" 
if this were to happen at boot up.  I could put together a patch.


Running System:
If this happens after the system is up and running, I'd think one is 
going to have some data in dmeg probably to the tune of "media error" 
... so in my mind, who cares about that case.


Regards,

Tom


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: runaway loop modprobe binfmt-0000

[Tom Gall]

Hi Andrew,

Thanks for the email back.

Andrew Morton wrote:


On Thu, 03 Jan 2008 12:18:19 -0600 Tom Gall [EMAIL PROTECTED] wrote:
 

This is an interesting one as I just hit this with a 2.6.23.12 kernel 
...  granted running on systemsim (the powerpc simulator) ... but as I'm 
hitting a wall I dropped in the dump_stack call and here is the output:
   



I don't remember what any of this is about and there is no record on the
mailing list - presumably because you're ccing [EMAIL PROTECTED] and not
[EMAIL PROTECTED]
 

Ever written the previous year on your checks? Well when I was googling 
about for folks with similar woes, the posts I had thought were from 
this January were actually from Jan 2007.  O Well! Not to mention it's 
been awhile since I've posted to lkml 


I suggest that we start again with this bug report from scratch.  
 

In this case, not needed. I spent friday taking a tour of the codepath 
and basically narrowed it down to a device driver passing bum data.


So if this ever happens in the future and someone somewhere seems the 
message about trying to load binfmt- (where  is  or some 
other random number * (hold that thought I'll come back to this) ) 
here are some things to consider as you're debugging your problem.


In my case, the device driver was just good enough that it could access 
the device, but was poor enough that the bits it was loading were 
complete crap ...   So the kernel was happily running along booting, 
gets to the point where it's time to exec init, loads the first bits of 
the binary, does a compare to make sure it's an elf binary, fails the 
compare (because the data is junk) ...  the kernel figures that ooo .. 
this data must be good it's just in a different format ... I'll run 
through the list of known binary file formats.. hmm not that one .. or 
that one    then running out of options trys to load a module for 
what must be this amazing new file format, can't find the module and 
ker-blew-ee.


* So this number that is part of the module name binfmt- is from 
what I see the id of the file format ... thankfully no one has choosen 
 as their id ...



Unless it's a potential denial-of-service attack for unprivileged users,
in which case a cc to [EMAIL PROTECTED] migt be more appropriate.
 

As this is a boot time issue it's certainly not a DOS.  Now there might 
be value is thinking about this error path in the initial boot up of the 
kernel. The message is a bit obscure for what the real issue is. Still 
.. should one go back to the device and comfirm that the data received 
was actually reasonable? No.


So I think we have two cases here:

Bootup:
I could see a change where the system should probably panic with some 
sort of message like : Not able to exec %s, unrecognized file format 
if this were to happen at boot up.  I could put together a patch.


Running System:
If this happens after the system is up and running, I'd think one is 
going to have some data in dmeg probably to the tune of media error 
... so in my mind, who cares about that case.


Regards,

Tom


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Richard Henderson wrote:

> On Wed, Jun 27, 2001 at 02:07:37PM -0500, Tom Gall wrote:
> > Consider also in drivers/pci/pci.c:
> >
> > The function pci_bus_exists checks based on bus numbers. This function is
> > of course used by pci_alloc_primary_bus, which is in turn used by
> > pci_scan_bus. As is today, this code can break me the second I'm
> > onto my second PCI system domain.
>
> You'll find that the existing ports that support multiple pci
> domains do not number the busses on the secondary domains from
> zero.  If domain 0 has 3 busses, then domain 1's root bus will
> be bus number 3, and so on.

Yes I've looked at this in depth, and it does work well to compact things down
and conserve on the precious and limited bus numbers.

> This approach works quite well in practice, even on machines
> with large numbers of pci domains, since there tends to be no
> pci-pci busses on domains other than the one containing legacy
> i/o widgetry.

We have pci-pci bridges in every PCI system domain. Additionally we have cards
that have pci-pci bridges on them and certainly they can be plugged in anywhere
on the system.

Unfortunately the majority of our problem is centered on the fact that in the
end we have more than 256 buses. I look forward to this limit disappearing in
2.5.

Regards,

Tom

--
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Richard Henderson wrote:

 On Wed, Jun 27, 2001 at 02:07:37PM -0500, Tom Gall wrote:
  Consider also in drivers/pci/pci.c:
 
  The function pci_bus_exists checks based on bus numbers. This function is
  of course used by pci_alloc_primary_bus, which is in turn used by
  pci_scan_bus. As is today, this code can break me the second I'm
  onto my second PCI system domain.

 You'll find that the existing ports that support multiple pci
 domains do not number the busses on the secondary domains from
 zero.  If domain 0 has 3 busses, then domain 1's root bus will
 be bus number 3, and so on.

Yes I've looked at this in depth, and it does work well to compact things down
and conserve on the precious and limited bus numbers.

 This approach works quite well in practice, even on machines
 with large numbers of pci domains, since there tends to be no
 pci-pci busses on domains other than the one containing legacy
 i/o widgetry.

We have pci-pci bridges in every PCI system domain. Additionally we have cards
that have pci-pci bridges on them and certainly they can be plugged in anywhere
on the system.

Unfortunately the majority of our problem is centered on the fact that in the
end we have more than 256 buses. I look forward to this limit disappearing in
2.5.

Regards,

Tom

--
Tom Gall - PPC64 Maintainer  Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Gérard Roudier wrote:
> 
> On Wed, 27 Jun 2001, Jeff Garzik wrote:
> 
> > Tom Gall wrote:
> > > Well you have device drivers like the symbios scsi driver for instance that
> > > tries to determine if it's seen a card before. It does this by looking at the
> > > bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> > > on the same bus number, same dev number etc yet they are in different PCI
> > > domains.
> > >
> > > Is this a device driver bug or feature?
> >
> > I hesitate to call it a device driver bug, because that was likely the
> > best decision Gerard could make at the time.
> >
> > However, I think the driver (only going by your description) would be
> > more correct to use a pointer to struct pci_dev.  We have a token in the
> > kernel that is guaranteed 100% unique to any given PCI device:  the
> > pointer to its struct pci_dev.
> 
> The driver checks against PCI bus+dev+func in 2 situations:
> 
> 1) To apply the boot order that user can set up in the controller NVRAMs.
> 2) To detect buggy double reporting of the same device by the kernel PCI
>code (this made lot of troubles at some time).

Thanks much for the clarification. Do you still battle buggy double reporting?
Has this been fixed? Is it a bug on some specific architecture?
 
> The great bug is to invent useless abstractions that don't match reality.
> Such brain masturbation leads to confusion (hence subtle bugs)  and
> useless software bloatage (thus _real_ resource wastage).

Agreed. (A couple of my posts last night didn't make it through... appears that
us.ibm.com isn't set up entirely right for ENC)

> If we want to handle _real_ PCI bus domains, we just have to add a domain
> number to identify a _real_ PCI device. Anything that wants to hide such
> reality in some opaque data looks like brain masturbation to me.

Again also agreed. Now I'm REALLY anxious for 2.5 8-)

>   Gérard.

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Gérard Roudier wrote:
 
 On Wed, 27 Jun 2001, Jeff Garzik wrote:
 
  Tom Gall wrote:
   Well you have device drivers like the symbios scsi driver for instance that
   tries to determine if it's seen a card before. It does this by looking at the
   bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
   on the same bus number, same dev number etc yet they are in different PCI
   domains.
  
   Is this a device driver bug or feature?
 
  I hesitate to call it a device driver bug, because that was likely the
  best decision Gerard could make at the time.
 
  However, I think the driver (only going by your description) would be
  more correct to use a pointer to struct pci_dev.  We have a token in the
  kernel that is guaranteed 100% unique to any given PCI device:  the
  pointer to its struct pci_dev.
 
 The driver checks against PCI bus+dev+func in 2 situations:
 
 1) To apply the boot order that user can set up in the controller NVRAMs.
 2) To detect buggy double reporting of the same device by the kernel PCI
code (this made lot of troubles at some time).

Thanks much for the clarification. Do you still battle buggy double reporting?
Has this been fixed? Is it a bug on some specific architecture?
 
 The great bug is to invent useless abstractions that don't match reality.
 Such brain masturbation leads to confusion (hence subtle bugs)  and
 useless software bloatage (thus _real_ resource wastage).

Agreed. (A couple of my posts last night didn't make it through... appears that
us.ibm.com isn't set up entirely right for ENC)

 If we want to handle _real_ PCI bus domains, we just have to add a domain
 number to identify a _real_ PCI device. Anything that wants to hide such
 reality in some opaque data looks like brain masturbation to me.

Again also agreed. Now I'm REALLY anxious for 2.5 8-)

   Gérard.

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Jeff Garzik wrote:

> Tom Gall wrote:
> > Well you have device drivers like the symbios scsi driver for instance that
> > tries to determine if it's seen a card before. It does this by looking at the
> > bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
> > on the same bus number, same dev number etc yet they are in different PCI
> > domains.
> >
> > Is this a device driver bug or feature?
>
> I hesitate to call it a device driver bug, because that was likely the
> best decision Gerard could make at the time.

I don't doubt it. I wouldn't doubt I've been guilty of simliar things in my past...


> However, I think the driver (only going by your description) would be
> more correct to use a pointer to struct pci_dev.  We have a token in the
> kernel that is guaranteed 100% unique to any given PCI device:  the
> pointer to its struct pci_dev.

Sound good.

> > > Changing the meaning of dev->bus->number globally seems pointless.  If
> > > you are going to do that, just do it the right way and introduce another
> > > struct member, pci_domain or somesuch.
>
> Sorry, not pci_domain, just system bus number, for any bus, like we
> talked about in the previous discussion.

Yes agreed. However do you think it's possible for the additional of such a value now
in 2.4.x series? Alan? Linus?

Regards,

Tom
--
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Jeff Garzik wrote:
> 
> Tom Gall wrote:
> >   The first part changes number, primary, and secondary to unsigned ints from
> > chars. What we do is encode the PCI "domain" aka PCI Primary Host Bridge, aka
> > pci controller in with the bus number. In our case we do it like this:
> >
> > pci_controller=dev->bus->number>>8) &0xFF
> > bus_number= dev->bus->number&0xFF),
> >
> >   Is this reasonable for everyone?
> 
> Why not use sysdata like the other arches?

Hi Jeff,

Well you have device drivers like the symbios scsi driver for instance that
tries to determine if it's seen a card before. It does this by looking at the
bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
on the same bus number, same dev number etc yet they are in different PCI
domains.

Is this a device driver bug or feature?

> Changing the meaning of dev->bus->number globally seems pointless.  If
> you are going to do that, just do it the right way and introduce another
> struct member, pci_domain or somesuch.

Right, one could do that and then all the large machine architectures would have
their own implementation for the same problem. That's not necessarily a bad
thing, but some commonality I think would be a good thing.
 
> Jeff

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RFC: Changes for PCI

[Tom Gall]

/*
- * $Id: pci.c,v 1.91 1999/01/21 13:34:01 davem Exp $
+ *
  *
  * PCI Bus Services, see include/linux/pci.h for further explanation.
  *
@@ -745,6 +745,14 @@
u32 l, sz;
struct resource *res;

+   /
+* Check for architecture dependant call to read the BARs.
+/
+   if(  dev->bus->ops->pci_read_bases != NULL) {
+   dev->bus->ops->pci_read_bases(dev, howmany, rom);
+   return;
+   }
+
for(pos=0; posresource[pos];
@@ -1026,6 +1034,14 @@
 static void pci_read_irq(struct pci_dev *dev)
 {
unsigned char irq;
+
+   /
+* Check for architecture dependant call to read and set irg
+/
+   if(dev->bus->ops->pci_read_irq != NULL) {
+   dev->bus->ops->pci_read_irq(dev);
+   return;
+   }

pci_read_config_byte(dev, PCI_INTERRUPT_PIN, );
if (irq)
@@ -1047,7 +1063,17 @@
 {
u32 class;

-   sprintf(dev->slot_name, "%02x:%02x.%d", dev->bus->number,
PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+   /* sprintf(dev->slot_name, "%02x:%02x.%d", dev->bus->number,
PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn)); */
+
+
+/
+ * Prefix the bus number with the phb number for large(>256 bus)
systems.
+ /
+   sprintf(dev->slot_name, "%4x%02x:%02x.%1x",
+   ( (dev->bus->number>>8) &0xFF),
+   (  dev->bus->number&0xFF),
+   PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn));
+
sprintf(dev->name, "PCI device %04x:%04x", dev->vendor, dev->device);

pci_read_config_dword(dev, PCI_CLASS_REVISION, );
@@ -1091,6 +1117,14 @@
printk(KERN_ERR "PCI: %s: class %x doesn't match header type %02x.
Ignoring class.\n",
   dev->slot_name, class, dev->hdr_type);
dev->class = PCI_CLASS_NOT_DEFINED;
+   }
+
+
+   /*
+* Give the architure code a chance to fix up/tweak the devices.
+*/
+   if(dev->bus->ops->pci_fixup_registers != NULL) {
+   dev->bus->ops->pci_fixup_registers(dev);
}

/* We found a fine healthy device, go go go... */

So as Joel from MST3K used to say, "What do you think sirs?"

Regards,

Tom


-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RFC: Changes for PCI

[Tom Gall]

 Bus Services, see include/linux/pci.h for further explanation.
  *
@@ -745,6 +745,14 @@
u32 l, sz;
struct resource *res;

+   /
+* Check for architecture dependant call to read the BARs.
+/
+   if(  dev-bus-ops-pci_read_bases != NULL) {
+   dev-bus-ops-pci_read_bases(dev, howmany, rom);
+   return;
+   }
+
for(pos=0; poshowmany; pos = next) {
next = pos+1;
res = dev-resource[pos];
@@ -1026,6 +1034,14 @@
 static void pci_read_irq(struct pci_dev *dev)
 {
unsigned char irq;
+
+   /
+* Check for architecture dependant call to read and set irg
+/
+   if(dev-bus-ops-pci_read_irq != NULL) {
+   dev-bus-ops-pci_read_irq(dev);
+   return;
+   }

pci_read_config_byte(dev, PCI_INTERRUPT_PIN, irq);
if (irq)
@@ -1047,7 +1063,17 @@
 {
u32 class;

-   sprintf(dev-slot_name, %02x:%02x.%d, dev-bus-number,
PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn));
+   /* sprintf(dev-slot_name, %02x:%02x.%d, dev-bus-number,
PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn)); */
+
+
+/
+ * Prefix the bus number with the phb number for large(256 bus)
systems.
+ /
+   sprintf(dev-slot_name, %4x%02x:%02x.%1x,
+   ( (dev-bus-number8) 0xFF),
+   (  dev-bus-number0xFF),
+   PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn));
+
sprintf(dev-name, PCI device %04x:%04x, dev-vendor, dev-device);

pci_read_config_dword(dev, PCI_CLASS_REVISION, class);
@@ -1091,6 +1117,14 @@
printk(KERN_ERR PCI: %s: class %x doesn't match header type %02x.
Ignoring class.\n,
   dev-slot_name, class, dev-hdr_type);
dev-class = PCI_CLASS_NOT_DEFINED;
+   }
+
+
+   /*
+* Give the architure code a chance to fix up/tweak the devices.
+*/
+   if(dev-bus-ops-pci_fixup_registers != NULL) {
+   dev-bus-ops-pci_fixup_registers(dev);
}

/* We found a fine healthy device, go go go... */

So as Joel from MST3K used to say, What do you think sirs?

Regards,

Tom


-- 
Tom Gall - PPC64 Maintainer  Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Changes for PCI

[Tom Gall]

Jeff Garzik wrote:

 Tom Gall wrote:
  Well you have device drivers like the symbios scsi driver for instance that
  tries to determine if it's seen a card before. It does this by looking at the
  bus,dev etc numbers...  It's quite reasonable for two different scsi cards to be
  on the same bus number, same dev number etc yet they are in different PCI
  domains.
 
  Is this a device driver bug or feature?

 I hesitate to call it a device driver bug, because that was likely the
 best decision Gerard could make at the time.

I don't doubt it. I wouldn't doubt I've been guilty of simliar things in my past...


 However, I think the driver (only going by your description) would be
 more correct to use a pointer to struct pci_dev.  We have a token in the
 kernel that is guaranteed 100% unique to any given PCI device:  the
 pointer to its struct pci_dev.

Sound good.

   Changing the meaning of dev-bus-number globally seems pointless.  If
   you are going to do that, just do it the right way and introduce another
   struct member, pci_domain or somesuch.

 Sorry, not pci_domain, just system bus number, for any bus, like we
 talked about in the previous discussion.

Yes agreed. However do you think it's possible for the additional of such a value now
in 2.4.x series? Alan? Linus?

Regards,

Tom
--
Tom Gall - PPC64 Maintainer  Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Going beyond 256 PCI buses

[Tom Gall]

"Albert D. Cahalan" wrote:
> 
> Tom Gall writes:
> 
> >   I was wondering if there are any other folks out there like me who
> > have the 256 PCI bus limit looking at them straight in the face?
> 
> I might. The need to reserve bus numbers for hot-plug looks like
> a quick way to waste all 256 bus numbers.

Hi Albert,

  yeah I'll be worring about this one too in time. Two birds with one stone
wouldn't be a bad thing. Hopefully it doesn't translate into needing a
significantly larger stone. 

> > each PHB has an
> > additional id, then each PHB can have up to 256 buses.
> 
> Try not to think of him as a PHB with an extra id. Lots of people
> have weird collections. If your boss wants to collect buses, well,
> that's his business. Mine likes boats. It's not a big deal, really.

Heh PHB==Primary Host Bridge  ... but I'll be sure to pass the word onto my
PHB that there's a used greyhound sale... 

Anyway, it really is a new id, at least for the implementation on this box. So
PHB0 could have 256 buses, and PHB1 could have 10 buses, PHB2 could have 
you get the idea.

Hot plug would still have the problem in that it'd have 256 bus numbers in the
namespace of a PHB to manage. Hot plug under a different PHB would have another
256 to play with.

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Going beyond 256 PCI buses

[Tom Gall]

  Anyway, Hi All,

  I was wondering if there are any other folks out there like me who
have the 256 PCI bus limit looking at them straight in the face? If so,
it'd be nice to collaborate and come up with a more general solution
that would hopefully work towards the greater good.

  I live in ppc64 land which is a new arch that the linux kernel has
been ported to. The boxes we run on tend to be big.

  The box that I'm wrestling with, has a setup where each PHB has an
additional id, then each PHB can have up to 256 buses.  So when you are
talking to a device, the scheme is phbid, bus, dev etc etc. Pretty easy
really.

  I am getting for putting something like this into the kernel at large,
it would probably be best to have a CONFIG_GREATER_THAN_256_BUSES or
some such.

  Anyways, thoughts? opinions?

--
Hakuna Matata,

Tom

---
ppc64 Maintainer IBM Linux Technology Center
"My heart is human, my blood is boiling, my brain IBM" -- Mr Roboto
[EMAIL PROTECTED]
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Going beyond 256 PCI buses

[Tom Gall]

Forgive if this is a dub... but the message I composed yesterday didn't
appear to be posted

  Anyway, Hi All,

  I was wondering if there are any other folks out there like me who
have the 256 PCI bus limit looking at them straight in the face? If so,
it'd be nice to collaborate and come up with a more general solution
that would hopefully work towards the greater good.

  I live in ppc64 land which is a new arch that the linux kernel has
been ported to. The boxes we run on tend to be big.

  The box that I'm wrestling with, has a setup where each PHB has an
additional id, then each PHB can have up to 256 buses.  So when you are
talking to a device, the scheme is phbid, bus, dev etc etc. Pretty easy
really.

  I am getting for putting something like this into the kernel at large,
it would probably be best to have a CONFIG_GREATER_THAN_256_BUSES or
some such.

  Anyways, thoughts? opinions?

--
Hakuna Matata,

Tom

---
ppc64 Maintainer IBM Linux Technology Center
My heart is human, my blood is boiling, my brain IBM -- Mr Roboto
[EMAIL PROTECTED]
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Going beyond 256 PCI buses

[Tom Gall]

Albert D. Cahalan wrote:
 
 Tom Gall writes:
 
I was wondering if there are any other folks out there like me who
  have the 256 PCI bus limit looking at them straight in the face?
 
 I might. The need to reserve bus numbers for hot-plug looks like
 a quick way to waste all 256 bus numbers.

Hi Albert,

  yeah I'll be worring about this one too in time. Two birds with one stone
wouldn't be a bad thing. Hopefully it doesn't translate into needing a
significantly larger stone. 

  each PHB has an
  additional id, then each PHB can have up to 256 buses.
 
 Try not to think of him as a PHB with an extra id. Lots of people
 have weird collections. If your boss wants to collect buses, well,
 that's his business. Mine likes boats. It's not a big deal, really.

Heh PHB==Primary Host Bridge  ... but I'll be sure to pass the word onto my
PHB that there's a used greyhound sale... bah-bum-bum-tshhh

Anyway, it really is a new id, at least for the implementation on this box. So
PHB0 could have 256 buses, and PHB1 could have 10 buses, PHB2 could have 
you get the idea.

Hot plug would still have the problem in that it'd have 256 bus numbers in the
namespace of a PHB to manage. Hot plug under a different PHB would have another
256 to play with.

Regards,

Tom

-- 
Tom Gall - PPC64 Maintainer  Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: New iSeries Device Drivers (small update)

[Tom Gall]

Hi All,

  Please Apply.

  I've updated the patch that I had posted on Monday so it applies against
2.4.4-ac15, with -p1. 

  Rather than spam the list the patch is at 
ftp://ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev-vs-2.4.4-ac15.gz

  The major / minor numbers in the patch were approved by hpa before the freeze
so hopefully there isn't an issue with these drivers going in on that account.

  Thanks!
  
  Tom
-- 
Tom Gall - PPC64 "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: New iSeries Device Drivers (small update)

[Tom Gall]

Hi All,

  Please Apply.

  I've updated the patch that I had posted on Monday so it applies against
2.4.4-ac15, with -p1. 

  Rather than spam the list the patch is at 
ftp://ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev-vs-2.4.4-ac15.gz

  The major / minor numbers in the patch were approved by hpa before the freeze
so hopefully there isn't an issue with these drivers going in on that account.

  Thanks!
  
  Tom
-- 
Tom Gall - PPC64 Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: New iSeries Device Drivers

[Tom Gall]

Hi All,

Enclosed you will find for your consideration a set of new device drivers for
iSeries boxes. This submission is against 2.4.4. 

Additionally in the background there is also a submission which has been made to
the ppc maintainers for the set of changes to arch/ppc and include/asm-ppc to
enable iSeries boxes to run Linux. Those should bubble up soon.

The new device drivers are for:

virtual console
virtual harddrive
virtual ethernet
virtual tape
virtual cd

These device drivers will also be used in the up coming ppc64 architecture.

Rather than spamming the list with ~6800 lines of driver code, you can obtain it
via 
http://www.ibm.com/linux/ltc/projects/ppc/patches/patch-lpar-dev.gz or via
ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev.gz

Background:

iSeries boxes are otherwise known as IBM's AS/400, a midrange business computer.
Linux runs on these machines in a logical partition, so akin to how the S390
runs Linux, iSeries allows you to have multiple Linux boxes running side by side
on the same machine. Since multiple linux boxes must share physical resources,
these virtual drivers were developed. The virtual ethernet goes a step beyond
and allows you to setup your own high speed lan "inside" of the box without
consuming physical resources.

Also see http://www.ibm.com/linux/ltc/projects/ppc/iSeries_notes.php or
http://www.ibm.com/servers/eserver/iseries/linux/ for more information.

Regards,

Tom
-- 
Tom Gall - PPC64 "Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PATCH: New iSeries Device Drivers

[Tom Gall]

Hi All,

Enclosed you will find for your consideration a set of new device drivers for
iSeries boxes. This submission is against 2.4.4. 

Additionally in the background there is also a submission which has been made to
the ppc maintainers for the set of changes to arch/ppc and include/asm-ppc to
enable iSeries boxes to run Linux. Those should bubble up soon.

The new device drivers are for:

virtual console
virtual harddrive
virtual ethernet
virtual tape
virtual cd

These device drivers will also be used in the up coming ppc64 architecture.

Rather than spamming the list with ~6800 lines of driver code, you can obtain it
via 
http://www.ibm.com/linux/ltc/projects/ppc/patches/patch-lpar-dev.gz or via
ftp.kernel.org/pub/linux/kernel/people/tgall/patch-lpar-dev.gz

Background:

iSeries boxes are otherwise known as IBM's AS/400, a midrange business computer.
Linux runs on these machines in a logical partition, so akin to how the S390
runs Linux, iSeries allows you to have multiple Linux boxes running side by side
on the same machine. Since multiple linux boxes must share physical resources,
these virtual drivers were developed. The virtual ethernet goes a step beyond
and allows you to setup your own high speed lan inside of the box without
consuming physical resources.

Also see http://www.ibm.com/linux/ltc/projects/ppc/iSeries_notes.php or
http://www.ibm.com/servers/eserver/iseries/linux/ for more information.

Regards,

Tom
-- 
Tom Gall - PPC64 Where's the ka-boom? There was
Linux Technology Center   supposed to be an earth
(w) [EMAIL PROTECTED] shattering ka-boom!
(w) 507-253-4558 -- Marvin Martian
(h) [EMAIL PROTECTED]
http://www.ibm.com/linux/ltc/projects/ppc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/