[OS-BUILD PATCH] [redhat] New configs in lib/Kconfig.debug
by CKI Gitlab (via Email Bridge)
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
[redhat] New configs in lib/Kconfig.debug
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_DEBUG_IRQFLAGS:
Enables checks for potentially unsafe enabling or disabling of
interrupts, such as calling raw_local_irq_restore() when interrupts
are enabled.
Symbol: DEBUG_IRQFLAGS [=n]
Type : bool
Defined at lib/Kconfig.debug:1427
Prompt: Debug IRQ flag manipulation
Location:
-> Kernel hacking
Selected by [n]:
- DEBUG_LOCKDEP [=n] && DEBUG_KERNEL [=y] && LOCKDEP [=n]
---
Cc: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
diff a/redhat/configs/common/generic/CONFIG_DEBUG_IRQFLAGS b/redhat/configs/common/generic/CONFIG_DEBUG_IRQFLAGS
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_DEBUG_IRQFLAGS
@@ -0,0 +1 @@
+# CONFIG_DEBUG_IRQFLAGS is not set
diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_IRQFLAGS b/redhat/configs/pending-common/generic/CONFIG_DEBUG_IRQFLAGS
--- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_IRQFLAGS
+++ /dev/null
@@ -1,18 +0,0 @@
-# CONFIG_DEBUG_IRQFLAGS:
-#
-# Enables checks for potentially unsafe enabling or disabling of
-# interrupts, such as calling raw_local_irq_restore() when interrupts
-# are enabled.
-#
-# Symbol: DEBUG_IRQFLAGS [=n]
-# Type : bool
-# Defined at lib/Kconfig.debug:1427
-# Prompt: Debug IRQ flag manipulation
-# Location:
-# -> Kernel hacking
-# Selected by [n]:
-# - DEBUG_LOCKDEP [=n] && DEBUG_KERNEL [=y] && LOCKDEP [=n]
-#
-#
-#
-# CONFIG_DEBUG_IRQFLAGS is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/912
15 hours, 32 minutes
[OS-BUILD PATCH] RHMAINTAINERS: Update DMA Mapping entry
by GitLab Bridge on behalf of prarit
From: Jerry Snitselaar <jsnitsel(a)redhat.com>
I'm taking over the primary role for DMA Mapping
so update the maintainers entry.
RH-Acked-by: Myron Stowe <mstowe(a)redhat.com
RH-Acked-by: Don Dutile <ddutile(a)redhat.com>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Cc: Donald Dutile <ddutile(a)redhat.com>
Signed-off-by: Jerry Snitselaar <jsnitsel(a)redhat.com>
---
redhat/rhdocs/MAINTAINERS/RHMAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
index dda356a9d5e9..df60e8537ff2 100644
--- a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
+++ b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
@@ -503,6 +503,7 @@ S: Maintained
F: drivers/scsi/hpsa*
DMA MAPPING SUPPORT
+M: Jerry Snitselaar <jsnitsel(a)redhat.com>
M: Donald Dutile <ddutile(a)redhat.com>
S: Maintained
F: kernel/dma/*
--
GitLab
1 day, 5 hours
[OS-BUILD PATCH] docs: Update docs to reflect newer workflow.
by GitLab Bridge on behalf of dzickusrh
From: Don Zickus <dzickus(a)redhat.com>
The workflow has recently changed such that all development is done
on the 'os-build' branch. Update the docs to show how easy it is
to make a change, commit it, generate the srpm and upload it to koji.
Also add it a build dep for making a srpm: patchutils (for filterdiff).
Cc: Bastien Nocera <bnocera(a)redhat.com>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Cc: Justin Forbes <jforbes(a)redhat.com>
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
---
redhat/docs/index.rst | 16 +++++-----------
redhat/docs/repository-layout.rst | 7 -------
redhat/docs/submitting-contributions.rst | 4 ++--
3 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/redhat/docs/index.rst b/redhat/docs/index.rst
index 951845cc7be3..b451b9ba49ca 100644
--- a/redhat/docs/index.rst
+++ b/redhat/docs/index.rst
@@ -36,8 +36,8 @@ Once GitLab finishes forking the repository (this can take a while):
git remote add -f upstream git@gitlab.com:cki-project/kernel-ark.git
# Install build dependencies
- sudo dnf install -y make gcc flex bison bzip2 rpm-build
- git checkout upstream/ark-latest
+ sudo dnf install -y make gcc flex bison bzip2 rpm-build patchutils
+ git checkout upstream/os-build
# If you're on Fedora, you need to run:
# ln -s /usr/bin/python3 /usr/libexec/platform-python
make dist-srpm
@@ -48,18 +48,11 @@ Building an SRPM
----------------
The configuration and build scripts are in the ``os-build`` branch and
-are regularly updated to work with Linus's master branch. To build an
-SRPM, start by checking out the source tree you'd like to build. In this
-example, we'll assume that is Linus's master branch, but it could just
-as easily be Fedora's ``ark-patches`` branch (Linus's tree + Fedora
-patches) , a sub-system maintainer's tree, or your own creation.
+are regularly updated to work with Linus's master branch.
::
- git checkout linus/master
- git merge -m "Merge branch 'os-build'" os-build
- # Fedora carries a patch to alter this setting, so we need to change the configuration to build a vanilla tree.
- # If you're targeting RHEL and have brew/rhpkg installed, use "make DIST=.elrdy dist-srpm" instead
+ git checkout upstream/os-build
make dist-srpm
You can now build the SRPM however you like:
@@ -70,6 +63,7 @@ You can now build the SRPM however you like:
mock redhat/rpm/SRPMS/kernel*src.rpm
# Build the SRPM in Fedora's Koji
koji build --scratch rawhide redhat/rpm/SRPMS/kernel*src.rpm
+ koji build --scratch eln redhat/rpm/SRPMS/kernel*src.rpm
Want to add a patch? Just git-cherry-pick it or apply it with git-am and
re-run ``make dist-srpm``. Change configurations in ``redhat/configs/``
diff --git a/redhat/docs/repository-layout.rst b/redhat/docs/repository-layout.rst
index 5f6dcb08a1bd..851a2c5d715b 100644
--- a/redhat/docs/repository-layout.rst
+++ b/redhat/docs/repository-layout.rst
@@ -63,13 +63,6 @@ along with the configuration and build scripts. They can be checked out
and built into RPMs. The ``master`` branch points to the latest version
of these branches.
-rhpatches
-~~~~~~~~~
-
-This branch is no longer used. Previously, it held the Red Hat patches
-for the kernel as a quilt series and remains for historical reasons.
-Patch history up to v5.4 is available in this branch.
-
Tags
----
diff --git a/redhat/docs/submitting-contributions.rst b/redhat/docs/submitting-contributions.rst
index 07b25852ec66..65895a9ce49b 100644
--- a/redhat/docs/submitting-contributions.rst
+++ b/redhat/docs/submitting-contributions.rst
@@ -39,8 +39,8 @@ Patches
Quick start:
1. ``git fetch upstream``
-2. ``git checkout upstream/os-build && git checkout -b my-build-change``
-3. Make a change to a file or files in ``redhat/``.
+2. ``git checkout -b my-build-change upstream/os-build``
+3. Make a change to a file.
4. Add your changes with ``git add -A``.
5. Commit your changes and write a nice commit message that explains the
change: ``git commit -s``.
--
GitLab
1 day, 7 hours
[OS-BUILD PATCH] [redhat] New configs in drivers/platform
by CKI Gitlab (via Email Bridge)
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
[redhat] New configs in drivers/platform
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_SURFACE_HOTPLUG:
Driver for out-of-band hot-plug event signaling on Microsoft Surface
devices with hot-pluggable PCIe cards.
This driver is used on Surface Book (2 and 3) devices with a
hot-pluggable discrete GPU (dGPU). When not in use, the dGPU on those
devices can enter D3cold, which prevents in-band (standard) PCIe
hot-plug signaling. Thus, without this driver, detaching the base
containing the dGPU will not correctly update the state of the
corresponding PCIe device if it is in D3cold. This driver adds support
for out-of-band hot-plug notifications, ensuring that the device state
is properly updated even when the device in question is in D3cold.
Select M or Y here, if you want to (fully) support hot-plugging of
dGPU devices on the Surface Book 2 and/or 3 during D3cold.
Symbol: SURFACE_HOTPLUG [=n]
Type : tristate
Defined at drivers/platform/surface/Kconfig:89
Prompt: Surface Hot-Plug Driver
Depends on: SURFACE_PLATFORMS [=y] && GPIOLIB [=y]
Location:
-> Device Drivers
-> Microsoft Surface Platform-Specific Device Drivers (SURFACE_PLATFORMS [=y])
---
CONFIG_X86_PLATFORM_DRIVERS_DELL:
Say Y here to get to see options for device drivers for various
Dell x86 platforms, including vendor-specific laptop extension drivers.
This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled.
Symbol: X86_PLATFORM_DRIVERS_DELL [=n]
Type : bool
Defined at drivers/platform/x86/dell/Kconfig:6
Prompt: Dell X86 Platform Specific Device Drivers
Depends on: X86 [=y] && X86_PLATFORM_DEVICES [=y]
Location:
-> Device Drivers
-> X86 Platform Specific Device Drivers (X86_PLATFORM_DEVICES [=y])
---
Cc: David Arcari <darcari(a)redhat.com>
Cc: Mark Langsdorf <mlangsdo(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
diff a/redhat/configs/common/generic/CONFIG_SURFACE_HOTPLUG b/redhat/configs/common/generic/CONFIG_SURFACE_HOTPLUG
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_SURFACE_HOTPLUG
@@ -0,0 +1 @@
+# CONFIG_SURFACE_HOTPLUG is not set
diff a/redhat/configs/common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL b/redhat/configs/common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL
@@ -0,0 +1 @@
+# CONFIG_X86_PLATFORM_DRIVERS_DELL is not set
diff a/redhat/configs/pending-common/generic/CONFIG_SURFACE_HOTPLUG b/redhat/configs/pending-common/generic/CONFIG_SURFACE_HOTPLUG
--- a/redhat/configs/pending-common/generic/CONFIG_SURFACE_HOTPLUG
+++ /dev/null
@@ -1,29 +0,0 @@
-# CONFIG_SURFACE_HOTPLUG:
-#
-# Driver for out-of-band hot-plug event signaling on Microsoft Surface
-# devices with hot-pluggable PCIe cards.
-#
-# This driver is used on Surface Book (2 and 3) devices with a
-# hot-pluggable discrete GPU (dGPU). When not in use, the dGPU on those
-# devices can enter D3cold, which prevents in-band (standard) PCIe
-# hot-plug signaling. Thus, without this driver, detaching the base
-# containing the dGPU will not correctly update the state of the
-# corresponding PCIe device if it is in D3cold. This driver adds support
-# for out-of-band hot-plug notifications, ensuring that the device state
-# is properly updated even when the device in question is in D3cold.
-#
-# Select M or Y here, if you want to (fully) support hot-plugging of
-# dGPU devices on the Surface Book 2 and/or 3 during D3cold.
-#
-# Symbol: SURFACE_HOTPLUG [=n]
-# Type : tristate
-# Defined at drivers/platform/surface/Kconfig:89
-# Prompt: Surface Hot-Plug Driver
-# Depends on: SURFACE_PLATFORMS [=y] && GPIOLIB [=y]
-# Location:
-# -> Device Drivers
-# -> Microsoft Surface Platform-Specific Device Drivers (SURFACE_PLATFORMS [=y])
-#
-#
-#
-# CONFIG_SURFACE_HOTPLUG is not set
diff a/redhat/configs/pending-common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL b/redhat/configs/pending-common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL
--- a/redhat/configs/pending-common/generic/CONFIG_X86_PLATFORM_DRIVERS_DELL
+++ /dev/null
@@ -1,20 +0,0 @@
-# CONFIG_X86_PLATFORM_DRIVERS_DELL:
-#
-# Say Y here to get to see options for device drivers for various
-# Dell x86 platforms, including vendor-specific laptop extension drivers.
-# This option alone does not add any kernel code.
-#
-# If you say N, all options in this submenu will be skipped and disabled.
-#
-# Symbol: X86_PLATFORM_DRIVERS_DELL [=n]
-# Type : bool
-# Defined at drivers/platform/x86/dell/Kconfig:6
-# Prompt: Dell X86 Platform Specific Device Drivers
-# Depends on: X86 [=y] && X86_PLATFORM_DEVICES [=y]
-# Location:
-# -> Device Drivers
-# -> X86 Platform Specific Device Drivers (X86_PLATFORM_DEVICES [=y])
-#
-#
-#
-# CONFIG_X86_PLATFORM_DRIVERS_DELL is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/918
1 day, 9 hours
[OS-BUILD PATCH] [redhat] New configs in fs/nfs
by GitLab Bridge on behalf of redhat-patchlab
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
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_NFS_V4_2_READ_PLUS:
This is intended for developers only. The READ_PLUS operation has
been shown to have issues under specific conditions and should not
be used in production.
Symbol: NFS_V4_2_READ_PLUS [=n]
Type : bool
Defined at fs/nfs/Kconfig:209
Prompt: NFS: Enable support for the NFSv4.2 READ_PLUS operation
Depends on: NETWORK_FILESYSTEMS [=y] && NFS_V4_2 [=y]
Location:
-> File systems
-> Network File Systems (NETWORK_FILESYSTEMS [=y])
---
Cc: kernel-patches(a)redhat.com
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
.../common/generic/CONFIG_NFS_V4_2_READ_PLUS | 1 +
.../generic/CONFIG_NFS_V4_2_READ_PLUS | 18 ------------------
2 files changed, 1 insertion(+), 18 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_NFS_V4_2_READ_PLUS
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_NFS_V4_2_READ_PLUS
diff --git a/redhat/configs/common/generic/CONFIG_NFS_V4_2_READ_PLUS b/redhat/configs/common/generic/CONFIG_NFS_V4_2_READ_PLUS
new file mode 100644
index 000000000000..4d62001f1f91
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_NFS_V4_2_READ_PLUS
@@ -0,0 +1 @@
+# CONFIG_NFS_V4_2_READ_PLUS is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_NFS_V4_2_READ_PLUS b/redhat/configs/pending-common/generic/CONFIG_NFS_V4_2_READ_PLUS
deleted file mode 100644
index 5a90e4f7db16..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_NFS_V4_2_READ_PLUS
+++ /dev/null
@@ -1,18 +0,0 @@
-# CONFIG_NFS_V4_2_READ_PLUS:
-#
-# This is intended for developers only. The READ_PLUS operation has
-# been shown to have issues under specific conditions and should not
-# be used in production.
-#
-# Symbol: NFS_V4_2_READ_PLUS [=n]
-# Type : bool
-# Defined at fs/nfs/Kconfig:209
-# Prompt: NFS: Enable support for the NFSv4.2 READ_PLUS operation
-# Depends on: NETWORK_FILESYSTEMS [=y] && NFS_V4_2 [=y]
-# Location:
-# -> File systems
-# -> Network File Systems (NETWORK_FILESYSTEMS [=y])
-#
-#
-#
-# CONFIG_NFS_V4_2_READ_PLUS is not set
--
GitLab
1 day, 9 hours
Dealing with i915 graphics issues reported by multipe people in
kernel >= 5.10.9
by Hans de Goede
Hi,
I've been working with various reporters to try and get the sometimes severe
gfx glitches which people are seeing with kernel >= 5.10.9 resolved, see the
following bugs:
1843274 - i915 GPU Hang with kernel 5.7 on Haswell (Acer C720P Chromebook)
1925346 - Screen glitches after updating to Kernel 5.10.10
1925903 - Flickering UI elements, screen instability (Wayland)
1931065 - Frequent i915 hangs
I've written 2 patches 2 address this and asked users to test Fedora-kernel
scratch-builds with those patches added.
The first patch is i915-revert.patch, this reverts 3 troublesome commits
which were first added in 5.10.9 these commit change the i915 mitigations
for a year old i915 CVE which IIRC was mostly about data leaking from a
previous GPU context to the next. These patches enable these mitigations
on more GPU models, where they were previously disabled because they were
causing issues...
Reporters have reported a 100% success-rate in getting rid of the gfx
issues with these 3 reverts.
The second patch is i915-fixes.patch, this cherry-picks 3 patches from
-next instead (these were suggested by i915 upstream) and this also helps
for most users, but some users still report some rendering artifacts
(but overall things are much better).
Upstream has gone silent on the issue of there still being rendering
artifacts with the 3 cherry-picked fixes unfortunately.
Given that we are getting more and more bug-reports about this I think
that we should be do something about this downstream. Upstream seams
to be aiming for fixing things, rather then reverting, so going with
i915-fixes.patch will stay the closest to what I expect to land in
5.10.y and 5.11.y at some point.
Regards,
Hans
4 days, 14 hours
[OS-BUILD PATCH] [redhat] New configs in arch/powerpc
by GitLab Bridge on behalf of jeremycline
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
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_CMDLINE:
On some platforms, there is currently no way for the boot loader to
pass arguments to the kernel. For these platforms, you can supply
some command-line options at build time by entering them here. In
most cases you will need to specify the root device here.
Symbol: CMDLINE [=]
Type : string
Defined at arch/powerpc/Kconfig:882
Prompt: Initial kernel command string
Location:
-> Kernel options
---
CONFIG_PPC_QUEUED_SPINLOCKS:
Say Y here to use queued spinlocks which give better scalability and
fairness on large SMP and NUMA systems without harming single threaded
performance.
This option is currently experimental, the code is more complex and
less tested so it defaults to "N" for the moment.
If unsure, say "N".
Symbol: PPC_QUEUED_SPINLOCKS [=n]
Type : bool
Defined at arch/powerpc/Kconfig:497
Prompt: Queued spinlocks
Depends on: SMP [=y]
Location:
-> Kernel options
---
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
redhat/configs/common/generic/CONFIG_CMDLINE | 1 +
.../generic/CONFIG_PPC_QUEUED_SPINLOCKS | 1 +
.../pending-common/generic/CONFIG_CMDLINE | 17 --------------
.../generic/CONFIG_PPC_QUEUED_SPINLOCKS | 22 -------------------
4 files changed, 2 insertions(+), 39 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_CMDLINE
create mode 100644 redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_CMDLINE
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
diff --git a/redhat/configs/common/generic/CONFIG_CMDLINE b/redhat/configs/common/generic/CONFIG_CMDLINE
new file mode 100644
index 000000000000..f3083e1e5200
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_CMDLINE
@@ -0,0 +1 @@
+CONFIG_CMDLINE=""
diff --git a/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
new file mode 100644
index 000000000000..f1f7e79da5c3
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
@@ -0,0 +1 @@
+# CONFIG_PPC_QUEUED_SPINLOCKS is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_CMDLINE b/redhat/configs/pending-common/generic/CONFIG_CMDLINE
deleted file mode 100644
index 10611732c5eb..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_CMDLINE
+++ /dev/null
@@ -1,17 +0,0 @@
-# CONFIG_CMDLINE:
-#
-# On some platforms, there is currently no way for the boot loader to
-# pass arguments to the kernel. For these platforms, you can supply
-# some command-line options at build time by entering them here. In
-# most cases you will need to specify the root device here.
-#
-# Symbol: CMDLINE [=]
-# Type : string
-# Defined at arch/powerpc/Kconfig:882
-# Prompt: Initial kernel command string
-# Location:
-# -> Kernel options
-#
-#
-#
-CONFIG_CMDLINE=""
diff --git a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS b/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
deleted file mode 100644
index 90ecdc77e696..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_PPC_QUEUED_SPINLOCKS
+++ /dev/null
@@ -1,22 +0,0 @@
-# CONFIG_PPC_QUEUED_SPINLOCKS:
-#
-# Say Y here to use queued spinlocks which give better scalability and
-# fairness on large SMP and NUMA systems without harming single threaded
-# performance.
-#
-# This option is currently experimental, the code is more complex and
-# less tested so it defaults to "N" for the moment.
-#
-# If unsure, say "N".
-#
-# Symbol: PPC_QUEUED_SPINLOCKS [=n]
-# Type : bool
-# Defined at arch/powerpc/Kconfig:497
-# Prompt: Queued spinlocks
-# Depends on: SMP [=y]
-# Location:
-# -> Kernel options
-#
-#
-#
-# CONFIG_PPC_QUEUED_SPINLOCKS is not set
--
GitLab
6 days, 23 hours
✅ PASS: Test report for kernel 5.10.19-200.fc33 (fedora-33)
by CKI Project
Hello,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.10.19-200.fc33
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=62729118
The results of these automated tests are provided below.
Overall result: PASSED
Tests: OK
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:
⚡ 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 - btrfs
🚧 ⚡⚡⚡ Storage blktests
🚧 ⚡⚡⚡ Storage block - filesystem fio test
🚧 ⚡⚡⚡ Storage block - queue scheduler test
🚧 ⚡⚡⚡ Storage nvme - tcp
🚧 ⚡⚡⚡ Storage: swraid mdadm raid_module test
🚧 ⚡⚡⚡ stress: stress-ng
ppc64le:
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
⚡⚡⚡ Loopdev Sanity
⚡⚡⚡ Memory: fork_mem
⚡⚡⚡ Memory function: memfd_create
⚡⚡⚡ AMTU (Abstract Machine Test Utility)
🚧 ⚡⚡⚡ CIFS Connectathon
🚧 ⚡⚡⚡ 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
⚡⚡⚡ LTP
⚡⚡⚡ Loopdev Sanity
⚡⚡⚡ Memory: fork_mem
⚡⚡⚡ Memory function: memfd_create
⚡⚡⚡ AMTU (Abstract Machine Test Utility)
🚧 ⚡⚡⚡ CIFS Connectathon
🚧 ⚡⚡⚡ Ethernet drivers sanity
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
🚧 ✅ Storage blktests
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: swraid mdadm raid_module test
🚧 ⚡⚡⚡ 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
✅ ACPI table test
⚡⚡⚡ LTP
⚡⚡⚡ Loopdev Sanity
⚡⚡⚡ Memory: fork_mem
⚡⚡⚡ Memory function: memfd_create
⚡⚡⚡ AMTU (Abstract Machine Test Utility)
🚧 ⚡⚡⚡ CIFS Connectathon
🚧 ⚡⚡⚡ Ethernet drivers sanity
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 ⏱.
6 days, 23 hours
A linux-5.11.1.tar.xz that actually contains 5.11 instead of 5.11.1?
by Thorsten Leemhuis
Lo! The new stable workflow based on kernel-ark confuses me and I want
to ask for advice if I got something wrong or if things are really as
they appear to me:
The sources file in dist.git for the Fedora 34 kernel currently(¹)
refers to a file that is called linux-5.11.1.tar.xz – but if you
download ("fedpkg sources") and unpack that file and look closer, you'll
notice that it actually contains the sources from Linux 5.11 (and not
5.11.1).
Is that intentional or just an mistake that someone did somewhere?
Because I find that really confusing.
Once I looked closer I noticed that the diff from Linux 5.11 -> 5.11.1
can actually be found in the file patch-5.11.1-redhat.patch (
https://src.fedoraproject.org/rpms/kernel/blob/f34/f/patch-5.11.1-redhat....
) - entangled with Fedora specific patches. I didn't try, but I'm
therefore pretty sure that rebuilding the kernel SRPM using
"--with-vanilla" (for details see
https://src.fedoraproject.org/rpms/kernel/blob/f34/f/kernel.spec
) will lead to unexpected results (I guess you will get a kernel that
partly thinks it's 5.11.1, but in truth is 5.11; if that acutally boot I
suspect users won't be able to spot this).
Are things really as described above or did I get something wrong?
Because it looks utterly confusing to me.
I have some issues with the whole kernel-ark workflow for a while now
and hence for a few week already considered asking on the Fedora
packaging list (the Fedora Packaging Committe's list) for advice if
kernel.spec violates the packaging guidelines too much (a complex
package like the kernel likely will always have some issues). I guess
this will finally make me do that, but before going down that route I
wanted to check here if I got something wrong.
CU, knurd
(¹) as of
https://src.fedoraproject.org/rpms/kernel/c/07992209452cd7ba529ffdbdd83d0...
1 week