❌ FAIL: Test report for kernel 5.11.21-200.fc33 (fedora-33)
by CKI Project
Hello,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.11.21-200.fc33
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=67992272
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Tests: FAILED
One or more kernel tests failed:
ppc64le:
❌ LTP
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
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.
For the full detail on our testing procedures, please scroll to the bottom of
this message.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ ACPI table test
✅ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ xarray-idr-radixtree-test
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ Storage: swraid mdadm raid_module test
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: lvm device-mapper test
🚧 ✅ stress: stress-ng
ppc64le:
Host 1:
✅ Boot test
❌ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ xarray-idr-radixtree-test
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ Storage: swraid mdadm raid_module test
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: lvm device-mapper test
s390x:
Host 1:
⚡ 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
✅ LTP
✅ CIFS Connectathon
⚡⚡⚡ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ xarray-idr-radixtree-test
Host 2:
✅ Boot test
✅ Storage: swraid mdadm raid_module test
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
🚧 ✅ stress: stress-ng
Host 3:
✅ Boot test
✅ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ❌ xarray-idr-radixtree-test
x86_64:
Host 1:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ xfstests - nfsv4.2
✅ Storage: swraid mdadm raid_module test
🚧 ❌ xfstests - btrfs
🚧 ✅ xfstests - cifsv3.11
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: lvm device-mapper test
🚧 ✅ stress: stress-ng
Host 2:
✅ Boot test
✅ ACPI table test
✅ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
🚧 ✅ xarray-idr-radixtree-test
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 ⏱.
2 years, 11 months
[OS-BUILD PATCH] [redhat] perf: enable dynamic linking of libbpf
by Michael Petlan (via Email Bridge)
From: Michael Petlan <mpetlan(a)redhat.com>
[redhat] perf: enable dynamic linking of libbpf
Bugzilla: https://bugzilla.redhat.com/1957210
Upstream: RHEL-only
description
===========
Enable dynamic linking of perf against libbpf. Also, libbpf-devel
becomes a build-dependency for kernel.src.rpm and libbpf becomes
a runtime dependency for perf.rpm.
Signed-off-by: Michael Petlan <mpetlan(a)redhat.com>
diff a/redhat/kernel.spec.template b/redhat/kernel.spec.template
--- a/redhat/kernel.spec.template
+++ b/redhat/kernel.spec.template
@@ -541,6 +541,7 @@ BuildRequires: sparse
BuildRequires: zlib-devel binutils-devel newt-devel perl(ExtUtils::Embed) bison flex xz-devel
BuildRequires: audit-libs-devel
BuildRequires: java-devel
+BuildRequires: libbpf-devel
%ifnarch %{arm} s390x
BuildRequires: numactl-devel
%endif
@@ -2053,7 +2054,7 @@ InitBuildVars
%endif
%global perf_make \
- %{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 prefix=%{_prefix} PYTHON=%{__python3}
+ %{__make} -s EXTRA_CFLAGS="${RPM_OPT_FLAGS}" LDFLAGS="%{__global_ldflags}" %{?cross_opts} -C tools/perf V=1 NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 LIBBPF_DYNAMIC=1 prefix=%{_prefix} PYTHON=%{__python3}
%if %{with_perf}
# perf
# make sure check-headers.sh is executable
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1111
2 years, 11 months
[OS-BUILD PATCH] [redhat] Embed crypto algos,
modes and templates needed in the FIPS mode
by Vladis Dronov (via Email Bridge)
From: Vladis Dronov <vdronov(a)redhat.com>
[redhat] Embed crypto algos, modes and templates needed in the FIPS mode
Currently a number of FIPS-allowed algorithms are built as modules or are
not enabled in Fedora and ARK. This can result in a panic while booting
in the FIPS mode. Fix this by embedding the FIPS-allowed algorithms, modes
and templates into a kernel, the same way as CTC, CBC and other algorithms
already do.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1947240
Signed-off-by: Vladis Dronov <vdronov(a)redhat.com>
diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4 b/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4
--- a/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_CRYPTO_LZ4 is not set
diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4HC b/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4HC
--- a/redhat/configs/ark/generic/CONFIG_CRYPTO_LZ4HC
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_CRYPTO_LZ4HC is not set
diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_XTS b/redhat/configs/ark/generic/CONFIG_CRYPTO_XTS
--- a/redhat/configs/ark/generic/CONFIG_CRYPTO_XTS
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_CRYPTO_XTS=m
diff a/redhat/configs/ark/generic/CONFIG_CRYPTO_ZSTD b/redhat/configs/ark/generic/CONFIG_CRYPTO_ZSTD
--- a/redhat/configs/ark/generic/CONFIG_CRYPTO_ZSTD
+++ /dev/null
@@ -1 +0,0 @@
-# CONFIG_CRYPTO_ZSTD is not set
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_AUTHENC b/redhat/configs/common/generic/CONFIG_CRYPTO_AUTHENC
--- a/redhat/configs/common/generic/CONFIG_CRYPTO_AUTHENC
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_AUTHENC
@@ -1 +1 @@
-CONFIG_CRYPTO_AUTHENC=m
+CONFIG_CRYPTO_AUTHENC=y
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_CCM b/redhat/configs/common/generic/CONFIG_CRYPTO_CCM
--- a/redhat/configs/common/generic/CONFIG_CRYPTO_CCM
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_CCM
@@ -1 +1 @@
-CONFIG_CRYPTO_CCM=m
+CONFIG_CRYPTO_CCM=y
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_CMAC b/redhat/configs/common/generic/CONFIG_CRYPTO_CMAC
--- a/redhat/configs/common/generic/CONFIG_CRYPTO_CMAC
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_CMAC
@@ -1 +1 @@
-CONFIG_CRYPTO_CMAC=m
+CONFIG_CRYPTO_CMAC=y
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4 b/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4
@@ -0,0 +1 @@
+CONFIG_CRYPTO_LZ4=y
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4HC b/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4HC
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_LZ4HC
@@ -0,0 +1 @@
+CONFIG_CRYPTO_LZ4HC=y
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_NULL b/redhat/configs/common/generic/CONFIG_CRYPTO_NULL
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_NULL
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_NULL
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_OFB b/redhat/configs/common/generic/CONFIG_CRYPTO_OFB
--- a/redhat/configs/common/generic/CONFIG_CRYPTO_OFB
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_OFB
@@ -1 +1 @@
-CONFIG_CRYPTO_OFB=m
+CONFIG_CRYPTO_OFB=y
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_RSA b/redhat/configs/common/generic/CONFIG_CRYPTO_RSA
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_RSA
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_RSA
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_SHA3 b/redhat/configs/common/generic/CONFIG_CRYPTO_SHA3
--- a/redhat/configs/common/generic/CONFIG_CRYPTO_SHA3
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_SHA3
@@ -1 +1 @@
-CONFIG_CRYPTO_SHA3=m
+CONFIG_CRYPTO_SHA3=y
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_XTS b/redhat/configs/common/generic/CONFIG_CRYPTO_XTS
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_XTS
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_XTS
diff a/redhat/configs/common/generic/CONFIG_CRYPTO_ZSTD b/redhat/configs/common/generic/CONFIG_CRYPTO_ZSTD
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CRYPTO_ZSTD
@@ -0,0 +1 @@
+CONFIG_CRYPTO_ZSTD=y
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4 b/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_CRYPTO_LZ4=m
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4HC b/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4HC
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_LZ4HC
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_CRYPTO_LZ4HC=m
diff a/redhat/configs/fedora/generic/CONFIG_CRYPTO_ZSTD b/redhat/configs/fedora/generic/CONFIG_CRYPTO_ZSTD
--- a/redhat/configs/fedora/generic/CONFIG_CRYPTO_ZSTD
+++ /dev/null
@@ -1 +0,0 @@
-CONFIG_CRYPTO_ZSTD=m
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1125
2 years, 11 months
[OS-BUILD PATCHv2 0/0] [redhat] New configs in fs/netfs
by CKI Gitlab (via Email Bridge)
From: CKI Gitlab on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1057
NOTE: Truncated patchset due to missing @redhat.com email
address on your GitLab profile at https://gitlab.com/-/profile.
Once that is fixed, close and reopen the merge request to
retrigger sending the emails.
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
CONFIG_NETFS_STATS:
This option causes statistical information to be gathered on local
caching and exported through file:
/proc/fs/fscache/stats
The gathering of statistics adds a certain amount of overhead to
execution as there are a quite a few stats gathered, and on a
multi-CPU system these may be on cachelines that keep bouncing
between CPUs. On the other hand, the stats are very useful for
debugging purposes. Saying 'Y' here is recommended.
Symbol: NETFS_STATS [=n]
Type : bool
Defined at fs/netfs/Kconfig:10
Prompt: Gather statistical information on local caching
Depends on: NETFS_SUPPORT [=m] && PROC_FS [=y]
Location:
-> File systems
-> Caches
-> Support for network filesystem high-level I/O (NETFS_SUPPORT
[=m])
---
CONFIG_NETFS_SUPPORT:
This option enables support for network filesystems, including
helpers for high-level buffered I/O, abstracting out read
segmentation, local caching and transparent huge page support.
Symbol: NETFS_SUPPORT [=m]
Type : tristate
Defined at fs/netfs/Kconfig:3
Prompt: Support for network filesystem high-level I/O
Location:
-> File systems
-> Caches
Selected by [m]:
- FSCACHE [=m]
Selected by [n]:
- AFS_FS [=n] && NETWORK_FILESYSTEMS [=y] && INET [=y]
---
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
2 years, 11 months
[OS-BUILD PATCH 0/0] [redhat] New configs in drivers/gpu
by CKI Gitlab (via Email Bridge)
From: CKI Gitlab on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1066
NOTE: Truncated patchset due to missing @redhat.com email
address on your GitLab profile at https://gitlab.com/-/profile.
Once that is fixed, close and reopen the merge request to
retrigger sending the emails.
Hi,
As part of the ongoing rebase effort, the following configuration
options need to be reviewed.
As a reminder, the ARK configuration flow involves moving unreviewed
configuration options from the pending directory to the ark directory.
In the diff below, options are removed from the pending directory and
added to the ark hierarchy. The final options that need to be ACKed
are the files that are being added to the ark hierarchy.
If the value for a file that is added should be changed, please reply
with a better option.
CONFIG_DRM_AMD_SECURE_DISPLAY:
Choose this option if you want to
support secure display
This option enables the calculation
of crc of specific region via debugfs.
Cooperate with specific DMCU FW.
Symbol: DRM_AMD_SECURE_DISPLAY [=n]
Type : bool
Defined at drivers/gpu/drm/amd/display/Kconfig:41
Prompt: Enable secure display support
Depends on: HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && DEBUG_FS
[=y] && DRM_AMD_DC_DCN [=y]
Location:
-> Device Drivers
-> Graphics support
-> AMD GPU (DRM_AMDGPU [=m])
-> Display Engine Configuration
---
CONFIG_DRM_CHIPONE_ICN6211:
ICN6211 is MIPI-DSI/RGB Converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
If in doubt, say "N".
Symbol: DRM_CHIPONE_ICN6211 [=n]
Type : tristate
Defined at drivers/gpu/drm/bridge/Kconfig:30
Prompt: Chipone ICN6211 MIPI-DSI/RGB Converter bridge
Depends on: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && OF [=y]
Location:
-> Device Drivers
-> Graphics support
-> Display Interface Bridges
Selects: DRM_MIPI_DSI [=n] && DRM_PANEL_BRIDGE [=y]
---
CONFIG_DRM_GUD:
This is a DRM display driver for GUD USB Displays or display
adapters.
If M is selected the module will be called gud.
Symbol: DRM_GUD [=n]
Type : tristate
Defined at drivers/gpu/drm/gud/Kconfig:3
Prompt: GUD USB Display
Depends on: HAS_IOMEM [=y] && DRM [=m] && USB [=y]
Location:
-> Device Drivers
-> Graphics support
Selects: LZ4_COMPRESS [=n] && DRM_KMS_HELPER [=m] &&
DRM_GEM_SHMEM_HELPER [=y] && BACKLIGHT_CLASS_DEVICE [=y]
---
CONFIG_DRM_LONTIUM_LT8912B:
Driver for Lontium LT8912B DSI to HDMI bridge
chip driver.
Please say Y if you have such hardware.
Say M here if you want to support this hardware as a module.
The module will be named "lontium-lt8912b".
Symbol: DRM_LONTIUM_LT8912B [=n]
Type : tristate
Defined at drivers/gpu/drm/bridge/Kconfig:64
Prompt: Lontium LT8912B DSI/HDMI bridge
Depends on: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && OF [=y]
Location:
-> Device Drivers
-> Graphics support
-> Display Interface Bridges
Selects: DRM_PANEL_BRIDGE [=y] && DRM_KMS_HELPER [=m] && DRM_MIPI_DSI
[=n] && REGMAP_I2C [=m]
---
CONFIG_DRM_XEN_FRONTEND:
Choose this option if you want to enable a para-virtualized
frontend DRM/KMS driver for Xen guest OSes.
Symbol: DRM_XEN_FRONTEND [=n]
Type : tristate
Defined at drivers/gpu/drm/xen/Kconfig:5
Prompt: Para-virtualized frontend driver for Xen guest OS
Depends on: HAS_IOMEM [=y] && XEN [=y] && DRM [=m]
Location:
-> Device Drivers
-> Graphics support
Selects: DRM_XEN [=n] && DRM_KMS_HELPER [=m] && VIDEOMODE_HELPERS [=n]
&& XEN_XENBUS_FRONTEND [=y] && XEN_FRONT_PGDIR_SHBUF [=m]
---
Cc: David Airlie <airlied(a)redhat.com>
Cc: Adam Jackson <ajax(a)redhat.com>
Cc: Lyude Paul <lyude(a)redhat.com>
Cc: Jeremy Cline <jcline(a)redhat.com>
Cc: "Michel Dänzer" <mdaenzer(a)redhat.com>
Cc: "Jérôme Glisse" <jglisse(a)redhat.com>
Cc: Karol Herbst <kherbst(a)redhat.com>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
2 years, 11 months
[OS-BUILD PATCH 0/4] redhat/configs: rework platform keys loading
by Bruno Meneguele (via Email Bridge)
From: Bruno Meneguele on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1127
This MR enable specific platform keys to be loaded in the integrity
platform
keyring (`.platform`). In the current state of the kernel the three
arches:
x86_64, aarch64, s390x, ppc, have the ability to pass their platform
(from
UEFI, IPL or PPC secur boot) enrolled keys to the system. With that,
I've
enabled the INTEGRITY_PLATFORM_KEYRING to the four platforms in both
RHEL
and Fedora and also their respective LOAD_*_KEYS.
With that, we are closer to upstream and also allow all platforms to
evolve
equaly during the next RHEL major release with Fedora users feedback.
56eef9231260 (Bruno Meneguele)
redhat: load specific ARCH keys to INTEGRITY_PLATFORM_KEYRING
66ed9a2826ba (Bruno Meneguele)
redhat: enable INTEGRITY_TRUSTED_KEYRING across all variants
b66b54c92054 (Bruno Meneguele)
redhat: enable SYSTEM_BLACKLIST_KEYRING across all variants
9a75ca99c03e (Bruno Meneguele)
redhat: enable INTEGRITY_ASYMMETRIC_KEYS across all variants
2 years, 11 months
❌ FAIL: Test report for kernel 5.11.20-200.fc33 (fedora-33)
by CKI Project
Hello,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.11.20-200.fc33
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=67761446
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Tests: FAILED
One or more kernel tests failed:
ppc64le:
❌ LTP
aarch64:
❌ LTP
x86_64:
❌ LTP
All kernel binaries, config files, and logs are available for download here:
https://arr-cki-prod-datawarehouse-public.s3.amazonaws.com/index.html?pre...
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.
For the full detail on our testing procedures, please scroll to the bottom of
this message.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Hardware testing
----------------
We booted each kernel and ran the following tests:
aarch64:
Host 1:
✅ Boot test
✅ ACPI table test
❌ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
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
✅ xfstests - ext4
✅ xfstests - xfs
✅ Storage: swraid mdadm raid_module test
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ⚡⚡⚡ Storage: lvm device-mapper test
🚧 ⚡⚡⚡ stress: stress-ng
ppc64le:
Host 1:
✅ Boot test
❌ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
Host 2:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ Storage: swraid mdadm raid_module test
🚧 ✅ xfstests - btrfs
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: lvm device-mapper test
s390x:
Host 1:
✅ Boot test
✅ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
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
✅ Storage: swraid mdadm raid_module test
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
🚧 ⚡⚡⚡ stress: stress-ng
x86_64:
Host 1:
⚡ 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
⚡⚡⚡ xfstests - ext4
⚡⚡⚡ xfstests - xfs
⚡⚡⚡ xfstests - nfsv4.2
⚡⚡⚡ Storage: swraid mdadm raid_module test
🚧 ⚡⚡⚡ xfstests - btrfs
🚧 ⚡⚡⚡ xfstests - cifsv3.11
🚧 ⚡⚡⚡ Storage blktests
🚧 ⚡⚡⚡ Storage block - filesystem fio test
🚧 ⚡⚡⚡ Storage block - queue scheduler test
🚧 ⚡⚡⚡ Storage nvme - tcp
🚧 ⚡⚡⚡ Storage: lvm device-mapper test
🚧 ⚡⚡⚡ stress: stress-ng
Host 2:
✅ Boot test
✅ ACPI table test
❌ LTP
✅ CIFS Connectathon
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
✅ Ethernet drivers sanity
Host 3:
✅ Boot test
✅ xfstests - ext4
✅ xfstests - xfs
✅ xfstests - nfsv4.2
✅ Storage: swraid mdadm raid_module test
🚧 ❌ xfstests - btrfs
🚧 ✅ xfstests - cifsv3.11
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ✅ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: lvm device-mapper test
🚧 ✅ stress: stress-ng
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 ⏱.
2 years, 11 months
[kernel-tests] branch master updated: /proc/sys/vm/drop_caches is
write only now
by pagure＠pagure.io
This is an automated email from the git hooks/post-receive script.
jforbes pushed a commit to branch master
in repository kernel-tests.
The following commit(s) were added to refs/heads/master by this push:
new 80f6ce8 /proc/sys/vm/drop_caches is write only now
80f6ce8 is described below
commit 80f6ce8ce53ef7678151338b6478aabab0af6d6b
Author: Justin M. Forbes <jforbes(a)fedoraproject.org>
AuthorDate: Wed May 12 15:33:25 2021 -0500
/proc/sys/vm/drop_caches is write only now
Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org>
---
default/cachedrop/drop_caches.sh | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/default/cachedrop/drop_caches.sh b/default/cachedrop/drop_caches.sh
index b6f0bf5..306f9f3 100755
--- a/default/cachedrop/drop_caches.sh
+++ b/default/cachedrop/drop_caches.sh
@@ -43,7 +43,8 @@ function free_pagecache()
sync
echo 1 > ${TUNE_FILE}
- verify_tune_value ${TUNE_FILE} 1
+ # /proc/sys/vm/drop_caches is write only now
+ # verify_tune_value ${TUNE_FILE} 1
sleep 1
new_pagecache=`vmstat | awk '{print $6}'| sed -n '3p'`
@@ -67,7 +68,8 @@ function free_dentries_inodes()
sync
echo 2 > ${TUNE_FILE}
- verify_tune_value ${TUNE_FILE} 2
+ # /proc/sys/vm/drop_caches is write only now
+ # verify_tune_value ${TUNE_FILE} 2
sleep 2
new_cache=`vmstat | awk '{print $6}'| sed -n '3p'`
@@ -93,7 +95,8 @@ function free_pagecache_dentries_inodes()
sync
echo 3 > ${TUNE_FILE}
- verify_tune_value ${TUNE_FILE} 3
+ # /proc/sys/vm/drop_caches is write only now
+ # verify_tune_value ${TUNE_FILE} 3
sleep 1
new_cache=`vmstat | awk '{print $6}'| sed -n '3p'`
--
To stop receiving notification emails like this one, please contact
the administrator of this repository.
2 years, 11 months
[OS-BUILD PATCH] Revert "nvme: multipath: Change default of kernel
NVMe
multipath to be disabled"
by Mike Snitzer (via Email Bridge)
From: Mike Snitzer <snitzer(a)redhat.com>
Revert "nvme: multipath: Change default of kernel NVMe multipath to be disabled"
This reverts commit 81cf9b7d49bb0a3786746e73d3090d97cefe301e.
The RHEL9 default will be native NVMe multipath _but_ RHEL9 will also
allow the ability to easily use dm-multipath on NVMe (by carrying
RHEL-only enablement) if nvme_core.multipath=N is set on the kernel
commandline.
Signed-off-by: Mike Snitzer <snitzer(a)redhat.com>
diff a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -8,11 +8,7 @@
#include <trace/events/block.h>
#include "nvme.h"
-#ifdef CONFIG_RHEL_DIFFERENCES
-static bool multipath = false;
-#else
static bool multipath = true;
-#endif
module_param(multipath, bool, 0444);
MODULE_PARM_DESC(multipath,
"turn on native support for multiple controllers per subsystem");
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1104
2 years, 11 months