----- Original Message ----- > Hardware testing > ---------------- > We booted each kernel and ran the following tests: > > aarch64: > Host 1: > ✅ Boot test > ✅ xfstests: ext4 > ✅ xfstests: xfs > ✅ selinux-policy: serge-testsuite > ✅ lvm thinp sanity > ✅ storage: software RAID testing > 🚧 ✅ Storage blktests > > Host 2: > > ⚡ Internal infrastructure issues prevented one or more tests (marked > with ⚡⚡⚡) from running on this architecture. > This is not the fault of the kernel that was tested. > > ✅ Boot test > ✅ Podman system integration test (as root) > ✅ Podman system integration test (as user) > ✅ Loopdev Sanity > ✅ jvm test suite > ✅ Memory function: memfd_create > ✅ AMTU (Abstract Machine Test Utility) > ✅ Ethernet drivers sanity > ✅ Networking socket: fuzz > ✅ Networking sctp-auth: sockopts test > ✅ Networking: igmp conformance test > ✅ Networking TCP: keepalive test > ✅ Networking UDP: socket > ✅ Networking tunnel: gre basic > ✅ Networking tunnel: vxlan basic > ✅ audit: audit testsuite test > ✅ httpd: mod_ssl smoke sanity > ✅ iotop: sanity > ✅ tuned: tune-processes-through-perf > ✅ Usex - version 1.9-29 > ✅ storage: SCSI VPD > 🚧 ⚡⚡⚡ LTP lite read_all_sys is triggering hard lockups on specific arm64 while reading /sys. LTP doesn't hit it 100%, but a plain "cat" or "hexdump" works reliable for me. Doesn't seem to be recent, Fedora's 5.0.9-301.fc30.aarch64 hanged too on same file. I sent a description to arm list: https://lore.kernel.org/linux-arm-kernel/1507592549.3785589.1570404050459.JavaMail.zimbra@xxxxxxxxxx/
