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

Viresh Kumar viresh.kumar at linaro.org
Wed Oct 7 01:33:45 EDT 2020


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.

-- 
viresh



More information about the linux-arm-kernel mailing list