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

[Tom Gall]

> On Oct 21, 2017, at 2:25 AM, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> 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