❌ 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