❌ FAIL: Test report for kernel 5.9.0-rc8 (arm-next)
Hello,
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:
One or more kernel tests failed:
aarch64:
❌ LTPWe hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message.
Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 1 architecture:
aarch64:
make options: make -j30 INSTALL_MOD_STRIP=1 targz-pkg
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ selinux-policy: serge-testsuite
✅ storage: software RAID testing
✅ stress: stress-ng
🚧 ✅ xfstests - btrfs
🚧 ❌ IPMI driver test
🚧 ✅ IPMItool loop stress test
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
Host 2:
✅ Boot test
✅ ACPI table test
✅ ACPI enabled test
✅ Podman system integration test - as root ✅ Podman system integration test - as user ❌ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity
✅ Networking socket: fuzz
✅ Networking: igmp conformance test
✅ Networking route: pmtu
✅ Networking route_func - local
✅ Networking route_func - forward
✅ Networking TCP: keepalive test
✅ Networking UDP: socket
✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic
✅ L2TP basic test
✅ Networking tunnel: vxlan basic
✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ Libkcapi AF_ALG test
✅ pciutils: update pci ids test
✅ ALSA PCM loopback test
✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD
🚧 ✅ CIFS Connectathon
🚧 ✅ POSIX pjd-fstest suites
🚧 ✅ Firmware test suite
🚧 ✅ jvm - jcstress tests
🚧 ✅ Memory function: kaslr
🚧 ✅ Ethernet drivers sanity
🚧 ✅ Networking firewall: basic netfilter test 🚧 ✅ audit: audit testsuite test
🚧 ✅ trace: ftrace/tracer
🚧 ✅ kdump - kexec_boot
Test sources: https://gitlab.com/cki-project/kernel-tests
💚 Pull requests are welcome for new tests or improvements to existing tests!
Aborted tests
-------------
Tests that didn't complete running successfully are marked with ⚡⚡⚡. If this was caused by an infrastructure issue, we try to mark that explicitly in the report.
Waived tests
------------
If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.
Testing timeout
---------------
We aim to provide a report within reasonable timeframe. Tests that haven't finished running yet are marked with ⏱.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 7 lines · CKI Project
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-kernelciThe results of these automated tests are provided below.
Quoted 8 lines
Overall result: FAILED (see details below)
Merge: OK
Compile: OK
Tests: FAILEDAll kernel binaries, config files, and logs are available for download here:
Hmm, this link doesn't seem to work (the '10' directory doesn't exist). Do I just need to wait a bit longer?
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
A message that is not in the archive (sent off-list or not yet received): [email protected]
[+Viresh as he wrote this test]
Quoted 30 lines · Iñaki Malerba
El 6/10/20 a las 10:22, Will Deacon escribió:
Quoted 13 lines · CKI Project
Quoted 12 lines
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-kernelciThe results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: OK
Tests: FAILEDQuoted 6 lines
Quoted 3 lines
All kernel binaries, config files, and logs are available for download here:
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-publicinstead ofdatawarehouse(with the correct prefix it should link to the correct folder).
Quoted 5 lines
The (now working) link is the following:
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).
It also looks like this test was only added to LTP in September, so that would explain why it appears to be a new failure.
Will
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 45 lines · Rachel Sibley
Quoted 42 lines · Will Deacon
[+Viresh as he wrote this test]
Quoted 30 lines · Iñaki Malerba
El 6/10/20 a las 10:22, Will Deacon escribió:
Quoted 13 lines · CKI Project
Quoted 12 lines
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-kernelciThe results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: OK
Tests: FAILEDQuoted 6 lines
Quoted 3 lines
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/614774Hmm, 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-publicinstead ofdatawarehouse(with the correct prefix it should link to the correct folder).Quoted 5 lines
The (now working) link is the following:
Sorry for the troubles,
Thanks, that works now. It looks like the failure is in the timed semaphore tests:
Quoted 6 lines
Quoted 6 lines
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.
Signature · 6 lines
viresh _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 61 lines · Viresh Kumar
Quoted 45 lines · Rachel Sibley
Quoted 42 lines · Will Deacon
[+Viresh as he wrote this test]
Quoted 30 lines · Iñaki Malerba
El 6/10/20 a las 10:22, Will Deacon escribió:
Quoted 13 lines · CKI Project
Quoted 12 lines
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-kernelciThe results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: OK
Tests: FAILEDQuoted 6 lines
Quoted 3 lines
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/614774Hmm, 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-publicinstead ofdatawarehouse(with the correct prefix it should link to the correct folder).Quoted 5 lines
The (now working) link is the following:
Sorry for the troubles,
Thanks, that works now. It looks like the failure is in the timed semaphore tests:
Quoted 6 lines
Quoted 6 lines
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:
(quoted diff) +1
-1- tst_ts_set_sec(&timeout, 0); + tst_ts_set_sec(&timeout, 2);
Quoted 2 lines
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
Quoted 1 line
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel