Please fix CONFIG_XHCI_PCI to be builtin rather then module
by Hans de Goede
Hi All,
An old problem with the XHCI driver has resurfaced, likely this was fixed in the
Fedora branched kernels but not in rawhide / the ARK kernels.
So now we again have users reporting that none of their USB ports work
any longer after installing the 5.10 kernel, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1917000
I believe that this is a regression caused by the XHCI driver being built as a module again, we had the same issue with 5.9 where we set CONFIG_USB_XHCI_PCI_RENESAS=m in the kernel config, but CONFIG_USB_XHCI_PCI actually depends on CONFIG_USB_XHCI_PCI_RENESAS (when the latter is not set to "n"), so selecting CONFIG_USB_XHCI_PCI_RENESAS=m forces CONFIG_USB_XHCI_PCI=m.
Like with 5.9 I have no idea why having XHCI as a module completely breaks XHCI support on some boards (*), but since we want it to be builtin anyways the fix is to set:
CONFIG_USB_XHCI_PCI=y
CONFIG_USB_XHCI_PCI_RENESAS=y
As we have in 5.9. I suspect that when this was fixed in 5.9, we forgot to port the fix to rawhide / to the ARK configs.
Can we please get this fixed asap for 5.10 (which is being shipped to
normal Fedora users now) and also fix this for rawhide and the ARK configs ?
Regards,
Hans
*) I suspect some ACPI power-resource getting turned off before loading the initrd, because it is not in use and this breaks XHCI support when the module loads later
3 years, 2 months
[OS-BUILD PATCH] Change email address for Justin Forbes
by Justin Forbes (via Email Bridge)
From: Justin M. Forbes <jforbes(a)fedoraproject.org>
Change email address for Justin Forbes
As RHMAINTAINERS is used for mapping acks and such. I would rather
change it to use the jforbes(a)fedoraproject.org address that I use for
commits and such.
Signed-off-by: Justin M. Forbes <jforbes(a)fedoraproject.org>
diff a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
--- a/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
+++ b/redhat/rhdocs/MAINTAINERS/RHMAINTAINERS
@@ -63,7 +63,7 @@ Red Hat Maintainers List (try to look for most precise areas first)
-----------------------------------
ARK Kernel Maintainer
-M: Justin Forbes <jforbes(a)redhat.com>
+M: Justin Forbes <jforbes(a)fedoraproject.org>
M: Patrick Talbert <ptalbert(a)redhat.com>
R: Donald Zickus <dzickus(a)redhat.com>
T: git https://gitlab.com/cki-project/kernel-ark.git
--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/866
3 years, 2 months
[OS-BUILD PATCH] [redhat] New configs in drivers/char
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_HW_RANDOM_XIPHERA:
This driver provides kernel-side support for Xiphera True Random
Number Generator Intellectual Property Core.
To compile this driver as a module, choose M here: the
module will be called xiphera-trng.
Symbol: HW_RANDOM_XIPHERA [=n]
Type : tristate
Defined at drivers/char/hw_random/Kconfig:529
Prompt: Xiphera FPGA based True Random Number Generator support
Depends on: HW_RANDOM [=y] && HAS_IOMEM [=y]
Location:
-> Device Drivers
-> Character devices
-> Hardware Random Number Generator Core support (HW_RANDOM [=y])
---
Cc: John Linville <linville(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
.../common/generic/CONFIG_HW_RANDOM_XIPHERA | 1 +
.../generic/CONFIG_HW_RANDOM_XIPHERA | 21 -------------------
2 files changed, 1 insertion(+), 21 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_HW_RANDOM_XIPHERA
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_HW_RANDOM_XIPHERA
diff --git a/redhat/configs/common/generic/CONFIG_HW_RANDOM_XIPHERA b/redhat/configs/common/generic/CONFIG_HW_RANDOM_XIPHERA
new file mode 100644
index 000000000000..779befaec438
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_HW_RANDOM_XIPHERA
@@ -0,0 +1 @@
+# CONFIG_HW_RANDOM_XIPHERA is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_HW_RANDOM_XIPHERA b/redhat/configs/pending-common/generic/CONFIG_HW_RANDOM_XIPHERA
deleted file mode 100644
index 0920b004cef4..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_HW_RANDOM_XIPHERA
+++ /dev/null
@@ -1,21 +0,0 @@
-# CONFIG_HW_RANDOM_XIPHERA:
-#
-# This driver provides kernel-side support for Xiphera True Random
-# Number Generator Intellectual Property Core.
-#
-# To compile this driver as a module, choose M here: the
-# module will be called xiphera-trng.
-#
-# Symbol: HW_RANDOM_XIPHERA [=n]
-# Type : tristate
-# Defined at drivers/char/hw_random/Kconfig:529
-# Prompt: Xiphera FPGA based True Random Number Generator support
-# Depends on: HW_RANDOM [=y] && HAS_IOMEM [=y]
-# Location:
-# -> Device Drivers
-# -> Character devices
-# -> Hardware Random Number Generator Core support (HW_RANDOM [=y])
-#
-#
-#
-# CONFIG_HW_RANDOM_XIPHERA is not set
--
GitLab
3 years, 2 months
[OS-BUILD PATCH] [redhat] New configs in drivers/net/wireless
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_ATH11K:
This module adds support for Qualcomm Technologies 802.11ax family of
chipsets.
If you choose to build a module, it'll be called ath11k.
Symbol: ATH11K [=n]
Type : tristate
Defined at drivers/net/wireless/ath/ath11k/Kconfig:2
Prompt: Qualcomm Technologies 802.11ax chipset support
Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=m] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=m]
Location:
-> Device Drivers
-> Network device support (NETDEVICES [=y])
-> Wireless LAN (WLAN [=y])
-> Atheros/Qualcomm devices (WLAN_VENDOR_ATH [=y])
Selects: ATH_COMMON [=m] && QCOM_QMI_HELPERS [=n]
---
Cc: Jarod Wilson <jarod(a)redhat.com>
Cc: John Linville <linville(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
redhat/configs/common/generic/CONFIG_ATH11K | 1 +
.../pending-common/generic/CONFIG_ATH11K | 22 -------------------
2 files changed, 1 insertion(+), 22 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_ATH11K
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_ATH11K
diff --git a/redhat/configs/common/generic/CONFIG_ATH11K b/redhat/configs/common/generic/CONFIG_ATH11K
new file mode 100644
index 000000000000..584c5e3f1ebc
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_ATH11K
@@ -0,0 +1 @@
+# CONFIG_ATH11K is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_ATH11K b/redhat/configs/pending-common/generic/CONFIG_ATH11K
deleted file mode 100644
index f591e2d0ff76..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_ATH11K
+++ /dev/null
@@ -1,22 +0,0 @@
-# CONFIG_ATH11K:
-#
-# This module adds support for Qualcomm Technologies 802.11ax family of
-# chipsets.
-#
-# If you choose to build a module, it'll be called ath11k.
-#
-# Symbol: ATH11K [=n]
-# Type : tristate
-# Defined at drivers/net/wireless/ath/ath11k/Kconfig:2
-# Prompt: Qualcomm Technologies 802.11ax chipset support
-# Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=m] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=m]
-# Location:
-# -> Device Drivers
-# -> Network device support (NETDEVICES [=y])
-# -> Wireless LAN (WLAN [=y])
-# -> Atheros/Qualcomm devices (WLAN_VENDOR_ATH [=y])
-# Selects: ATH_COMMON [=m] && QCOM_QMI_HELPERS [=n]
-#
-#
-#
-# CONFIG_ATH11K is not set
--
GitLab
3 years, 2 months
[OS-BUILD PATCH] [redhat] New configs in lib/Kconfig.debug
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_FAULT_INJECTION_USERCOPY:
Provides fault-injection capability to inject failures
in usercopy functions (copy_from_user(), get_user(), ...).
Symbol: FAULT_INJECTION_USERCOPY [=n]
Type : bool
Defined at lib/Kconfig.debug:1771
Prompt: Fault injection capability for usercopy functions
Depends on: FAULT_INJECTION [=y]
Location:
-> Kernel hacking
-> Kernel Testing and Coverage
-> Fault-injection framework (FAULT_INJECTION [=y])
---
Cc: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Fedora Kernel Team <kernel-team(a)fedoraproject.org>
---
.../generic/CONFIG_FAULT_INJECTION_USERCOPY | 1 +
.../generic/CONFIG_FAULT_INJECTION_USERCOPY | 18 ------------------
2 files changed, 1 insertion(+), 18 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_FAULT_INJECTION_USERCOPY
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_FAULT_INJECTION_USERCOPY
diff --git a/redhat/configs/common/generic/CONFIG_FAULT_INJECTION_USERCOPY b/redhat/configs/common/generic/CONFIG_FAULT_INJECTION_USERCOPY
new file mode 100644
index 000000000000..5a57de6d5a6c
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_FAULT_INJECTION_USERCOPY
@@ -0,0 +1 @@
+# CONFIG_FAULT_INJECTION_USERCOPY is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_FAULT_INJECTION_USERCOPY b/redhat/configs/pending-common/generic/CONFIG_FAULT_INJECTION_USERCOPY
deleted file mode 100644
index f48e0d1d8ccf..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_FAULT_INJECTION_USERCOPY
+++ /dev/null
@@ -1,18 +0,0 @@
-# CONFIG_FAULT_INJECTION_USERCOPY:
-#
-# Provides fault-injection capability to inject failures
-# in usercopy functions (copy_from_user(), get_user(), ...).
-#
-# Symbol: FAULT_INJECTION_USERCOPY [=n]
-# Type : bool
-# Defined at lib/Kconfig.debug:1771
-# Prompt: Fault injection capability for usercopy functions
-# Depends on: FAULT_INJECTION [=y]
-# Location:
-# -> Kernel hacking
-# -> Kernel Testing and Coverage
-# -> Fault-injection framework (FAULT_INJECTION [=y])
-#
-#
-#
-# CONFIG_FAULT_INJECTION_USERCOPY is not set
--
GitLab
3 years, 2 months
[OS-BUILD PATCH] [redhat] New configs in drivers/leds
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_LEDS_LP50XX:
If you say yes here you get support for the Texas Instruments
LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver.
To compile this driver as a module, choose M here: the
module will be called leds-lp50xx.
Symbol: LEDS_LP50XX [=n]
Type : tristate
Defined at drivers/leds/Kconfig:398
Prompt: LED Support for TI LP5036/30/24/18/12/9 LED driver chip
Depends on: NEW_LEDS [=y] && LEDS_CLASS [=y] && REGMAP_I2C [=m] && (LEDS_CLASS_MULTICOLOR [=n] || !LEDS_CLASS_MULTICOLOR [=n])
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>
---
.../configs/common/generic/CONFIG_LEDS_LP50XX | 1 +
.../pending-common/generic/CONFIG_LEDS_LP50XX | 20 -------------------
2 files changed, 1 insertion(+), 20 deletions(-)
create mode 100644 redhat/configs/common/generic/CONFIG_LEDS_LP50XX
delete mode 100644 redhat/configs/pending-common/generic/CONFIG_LEDS_LP50XX
diff --git a/redhat/configs/common/generic/CONFIG_LEDS_LP50XX b/redhat/configs/common/generic/CONFIG_LEDS_LP50XX
new file mode 100644
index 000000000000..99ee0f5990b4
--- /dev/null
+++ b/redhat/configs/common/generic/CONFIG_LEDS_LP50XX
@@ -0,0 +1 @@
+# CONFIG_LEDS_LP50XX is not set
diff --git a/redhat/configs/pending-common/generic/CONFIG_LEDS_LP50XX b/redhat/configs/pending-common/generic/CONFIG_LEDS_LP50XX
deleted file mode 100644
index a48da6675067..000000000000
--- a/redhat/configs/pending-common/generic/CONFIG_LEDS_LP50XX
+++ /dev/null
@@ -1,20 +0,0 @@
-# CONFIG_LEDS_LP50XX:
-#
-# If you say yes here you get support for the Texas Instruments
-# LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver.
-#
-# To compile this driver as a module, choose M here: the
-# module will be called leds-lp50xx.
-#
-# Symbol: LEDS_LP50XX [=n]
-# Type : tristate
-# Defined at drivers/leds/Kconfig:398
-# Prompt: LED Support for TI LP5036/30/24/18/12/9 LED driver chip
-# Depends on: NEW_LEDS [=y] && LEDS_CLASS [=y] && REGMAP_I2C [=m] && (LEDS_CLASS_MULTICOLOR [=n] || !LEDS_CLASS_MULTICOLOR [=n])
-# Location:
-# -> Device Drivers
-# -> LED Support (NEW_LEDS [=y])
-#
-#
-#
-# CONFIG_LEDS_LP50XX is not set
--
GitLab
3 years, 2 months
[OS-BUILD PATCH] all: s390x: Increase CONFIG_PCI_NR_FUNCTIONS to 512
(#1888735)
by GitLab Bridge on behalf of sharkcz
From: =?UTF-8?q?Dan=20Hor=C3=A1k?= <dan(a)danny.cz>
Signed-off-by: Dan Horák <dan(a)danny.cz>
CC: Philipp Rudo <prudo(a)redhat.com>
CC: Steve Best <sbest(a)redhat.com>
---
redhat/configs/common/generic/s390x/CONFIG_PCI_NR_FUNCTIONS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/redhat/configs/common/generic/s390x/CONFIG_PCI_NR_FUNCTIONS b/redhat/configs/common/generic/s390x/CONFIG_PCI_NR_FUNCTIONS
index 5d60ce18485b..3855e841797f 100644
--- a/redhat/configs/common/generic/s390x/CONFIG_PCI_NR_FUNCTIONS
+++ b/redhat/configs/common/generic/s390x/CONFIG_PCI_NR_FUNCTIONS
@@ -1 +1 @@
-CONFIG_PCI_NR_FUNCTIONS=64
+CONFIG_PCI_NR_FUNCTIONS=512
--
GitLab
3 years, 2 months
❌ FAIL: Test report for kernel 5.10.8-200.fc33 (fedora-33)
by CKI Project
Hello,
We ran automated tests on the following kernel build:
Kernel package: kernel-5.10.8-200.fc33
Task URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=59909096
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Tests: FAILED
One or more kernel tests failed:
ppc64le:
❌ Boot test
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
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 2:
✅ Boot test
✅ stress: stress-ng
🚧 ✅ 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
ppc64le:
Host 1:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 2:
❌ 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
s390x:
Host 1:
✅ Boot test
✅ stress: stress-ng
🚧 ✅ Storage blktests
🚧 ❌ Storage nvme - tcp
🚧 ✅ Storage: swraid mdadm raid_module test
Host 2:
✅ Boot test
✅ LTP
✅ Loopdev Sanity
✅ Memory: fork_mem
✅ Memory function: memfd_create
✅ AMTU (Abstract Machine Test Utility)
🚧 ✅ CIFS Connectathon
🚧 ✅ Ethernet drivers sanity
Host 3:
✅ Boot test
✅ kdump - sysrq-c
x86_64:
Host 1:
✅ Boot test
✅ stress: stress-ng
🚧 ✅ xfstests - ext4
🚧 ✅ xfstests - xfs
🚧 ✅ xfstests - btrfs
🚧 ✅ xfstests - nfsv4.2
🚧 ✅ xfstests - cifsv3.11
🚧 ✅ Storage blktests
🚧 ✅ Storage block - filesystem fio test
🚧 ❌ Storage block - queue scheduler test
🚧 ✅ Storage nvme - tcp
🚧 ✅ Storage: swraid mdadm raid_module test
Host 2:
✅ Boot test
🚧 ✅ kdump - sysrq-c
Host 3:
✅ 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 ⏱.
3 years, 2 months