Re: ❌ FAIL: Test report for kernel 5.9.0-rc8 (arm-next)

[Rachel Sibley]

On 10/7/20 1:33 AM, Viresh Kumar wrote:
> On 06-10-20, 10:09, Rachel Sibley wrote:
>>
>>
>> On 10/6/20 8:45 AM, Will Deacon wrote:
>>> [+Viresh as he wrote this test]
>>>
>>> On Tue, Oct 06, 2020 at 12:54:59PM +0200, Iñaki Malerba wrote:
>>>> El 6/10/20 a las 10:22, Will Deacon escribió:
>>>>> On Tue, Oct 06, 2020 at 01:15:18AM -0000, CKI Project wrote:
>>>>>> We ran automated tests on a recent commit from this kernel tree:
>>>>>>
>>>>>>          Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
>>>>>>               Commit: e37569e28eea - Merge branch 'for-next/late-arrivals' into for-kernelci
>>>>>>
>>>>>> The results of these automated tests are provided below.
>>>>>>
>>>>>>       Overall result: FAILED (see details below)
>>>>>>                Merge: OK
>>>>>>              Compile: OK
>>>>>>                Tests: FAILED
>>>>>>
>>>>>> All kernel binaries, config files, and logs are available for download here:
>>>>>>
>>>>>>     https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse/2020/10/05/614774
>>>>>
>>>>> Hmm, this link doesn't seem to work (the '10' directory doesn't exist). Do I
>>>>> just need to wait a bit longer?
>>>>
>>>> Thanks for reporting this!
>>>>
>>>> There was a problem on the script that uploads the files. It's fixed now
>>>> and the files are deploying. In a few minutes everything should be there.
>>>>
>>>> Your report also made us realize the link is incorrect, as the prefix
>>>> should be `datawarehouse-public` instead of `datawarehouse` (with the
>>>> correct prefix it should link to the correct folder).
>>>>
>>>> The (now working) link is the following:
>>>>
>>>> https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?prefix=datawarehouse-public/2020/10/05/614774
>>>>
>>>> Sorry for the troubles,
>>>
>>> Thanks, that works now. It looks like the failure is in the timed semaphore
>>> tests:
>>>
>>> 	semop03.c:55: TFAIL: unexpected failure: EAGAIN/EWOULDBLOCK (11)
>>>
>>> where the text expects EINTR, but assumedly the timeout is kicking in
>>> so we get EAGAIN. I don't see how the arm64 tree can be causing that, and I
>>> rather suspect that the test is just racy (the timeout is pretty small --
>>> 10ms iiuc).
> 
> That is one possible explanation for sure.
> 
> Rachel, can you please increase the timeout to something sufficiently
> big enough and try again ? Something like this:
> 
> -       tst_ts_set_sec(&timeout, 0);
> +       tst_ts_set_sec(&timeout, 2);
> 
> I saw similar issues with very small timeouts and 10ms kind of worked
> all the time. I think we need to increase it further.

Thanks for your patch Viresh, just ran it on the same machine/kernel for 100 loops, and happy to confirm I no longer
see the failures, increasing the timeout worked well.

Thanks!
Rachel

>