[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_INFO_DWARF_TOOLCHAIN_DEFAULT:
The implicit default version of DWARF debug info produced by a
toolchain changes over time.
This can break consumers of the debug info that haven't upgraded to
support newer revisions, and prevent testing newer versions, but
those should be less common scenarios.
If unsure, say Y.
Symbol: DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT [=n]
Type : bool
Defined at lib/Kconfig.debug:264
Prompt: Rely on the toolchain's implicit default DWARF version
Depends on: <choice>
Location:
-> Kernel hacking
-> Compile-time checks and compiler options
-> Compile the kernel with debug info (DEBUG_INFO [=y])
-> DWARF version (<choice> [=y])
---
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_INFO_DWARF_TOOLCHAIN_DEFAULT b/redhat/configs/common/generic/CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
@@ -0,0 +1 @@
+# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
diff a/redhat/configs/pending-common/generic/CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT b/redhat/configs/pending-common/generic/CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
--- a/redhat/configs/pending-common/generic/CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
+++ /dev/null
@@ -1,25 +0,0 @@
-# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT:
-#
-# The implicit default version of DWARF debug info produced by a
-# toolchain changes over time.
-#
-# This can break consumers of the debug info that haven't upgraded to
-# support newer revisions, and prevent testing newer versions, but
-# those should be less common scenarios.
-#
-# If unsure, say Y.
-#
-# Symbol: DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT [=n]
-# Type : bool
-# Defined at lib/Kconfig.debug:264
-# Prompt: Rely on the toolchain's implicit default DWARF version
-# Depends on: <choice>
-# Location:
-# -> Kernel hacking
-# -> Compile-time checks and compiler options
-# -> Compile the kernel with debug info (DEBUG_INFO [=y])
-# -> DWARF version (<choice> [=y])
-#
-#
-#
-# CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/934
3 years, 1 month
[OS-BUILD PATCH] [redhat] New configs in lib/Kconfig
by CKI Gitlab (via Email Bridge)
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
[redhat] New configs in lib/Kconfig
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_STACK_HASH_ORDER:
Select the hash size as a power of 2 for the stackdepot hash table.
Choose a lower value to reduce the memory impact.
Symbol: STACK_HASH_ORDER [=20]
Type : integer
Range : [12 20]
Defined at lib/Kconfig:654
Prompt: stack depot hash size (12 => 4KB, 20 => 1024KB)
Depends on: STACKDEPOT [=y]
Location:
-> Library routines
---
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_STACK_HASH_ORDER b/redhat/configs/common/generic/CONFIG_STACK_HASH_ORDER
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_STACK_HASH_ORDER
@@ -0,0 +1 @@
+CONFIG_STACK_HASH_ORDER=20
diff a/redhat/configs/pending-common/generic/CONFIG_STACK_HASH_ORDER b/redhat/configs/pending-common/generic/CONFIG_STACK_HASH_ORDER
--- a/redhat/configs/pending-common/generic/CONFIG_STACK_HASH_ORDER
+++ /dev/null
@@ -1,17 +0,0 @@
-# CONFIG_STACK_HASH_ORDER:
-#
-# Select the hash size as a power of 2 for the stackdepot hash table.
-# Choose a lower value to reduce the memory impact.
-#
-# Symbol: STACK_HASH_ORDER [=20]
-# Type : integer
-# Range : [12 20]
-# Defined at lib/Kconfig:654
-# Prompt: stack depot hash size (12 => 4KB, 20 => 1024KB)
-# Depends on: STACKDEPOT [=y]
-# Location:
-# -> Library routines
-#
-#
-#
-CONFIG_STACK_HASH_ORDER=20
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/933
3 years, 1 month
[OS-BUILD PATCH] [redhat] New configs in drivers/leds
by CKI Gitlab (via Email Bridge)
From: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
[redhat] New configs in drivers/leds
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_LEDS_BLINK:
This option enables blink support for the leds class.
If unsure, say Y.
Symbol: LEDS_BLINK [=n]
Type : bool
Defined at drivers/leds/blink/Kconfig:1
Prompt: LED Blink support
Depends on: NEW_LEDS [=y] && LEDS_CLASS [=y]
Location:
-> Device Drivers
-> LED Support (NEW_LEDS [=y])
---
Cc: Tony Camuso <tcamuso(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
diff a/redhat/configs/common/generic/CONFIG_LEDS_BLINK b/redhat/configs/common/generic/CONFIG_LEDS_BLINK
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_LEDS_BLINK
@@ -0,0 +1 @@
+# CONFIG_LEDS_BLINK is not set
diff a/redhat/configs/pending-common/generic/CONFIG_LEDS_BLINK b/redhat/configs/pending-common/generic/CONFIG_LEDS_BLINK
--- a/redhat/configs/pending-common/generic/CONFIG_LEDS_BLINK
+++ /dev/null
@@ -1,17 +0,0 @@
-# CONFIG_LEDS_BLINK:
-#
-# This option enables blink support for the leds class.
-# If unsure, say Y.
-#
-# Symbol: LEDS_BLINK [=n]
-# Type : bool
-# Defined at drivers/leds/blink/Kconfig:1
-# Prompt: LED Blink support
-# Depends on: NEW_LEDS [=y] && LEDS_CLASS [=y]
-# Location:
-# -> Device Drivers
-# -> LED Support (NEW_LEDS [=y])
-#
-#
-#
-# CONFIG_LEDS_BLINK is not set
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/928
3 years, 1 month
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
3 years, 1 month