11.8. Noyau
Le pilote mlx5 échoue lors de l'utilisation de l'adaptateur Mellanox ConnectX-5
Dans le modèle de pilote de périphérique de commutateur Ethernet (switchdev), le pilote mlx5 échoue lorsqu'il est configuré avec le paramètre DMFS (device managed flow steering) et que l'adaptateur ConnectX-5 est pris en charge par le matériel. En conséquence, vous pouvez voir le message d'erreur suivant :
BUG: Bad page cache in process umount pfn:142b4b
Pour contourner ce problème, vous devez utiliser le paramètre SMFS (software managed flow steering) au lieu de DMFS.
(BZ#2180665)
L'activation de FADump avec Secure Boot peut entraîner une perte de mémoire (OOM) dans GRUB
Dans l'environnement Secure Boot, GRUB et PowerVM allouent ensemble une zone de mémoire de 512 Mo, connue sous le nom de Real Mode Area (RMA), pour la mémoire de démarrage. La région est divisée entre les composants de démarrage et, si l'un d'entre eux dépasse son allocation, des pannes de mémoire se produisent.
En général, le système de fichiers initramfs installé par défaut et la table de symboles vmlinux sont dans les limites permettant d'éviter de telles défaillances. Toutefois, si la fonction Firmware Assisted Dump (FADump) est activée dans le système, la taille par défaut de initramfs peut augmenter et dépasser 95 Mo. Par conséquent, chaque redémarrage du système entraîne un état GRUB OOM.
Pour éviter ce problème, n'utilisez pas Secure Boot et FADump en même temps. Pour plus d'informations et de méthodes sur la manière de contourner ce problème, voir https://www.ibm.com/support/pages/node/6846531.
(BZ#2149172)
weak-modules from kmod ne fonctionne pas avec les interdépendances de modules
Le script weak-modules fourni par le paquet kmod détermine quels modules sont compatibles avec les noyaux installés. Cependant, lors de la vérification de la compatibilité des modules avec le noyau, weak-modules traite les dépendances des symboles des modules de la version supérieure à la version inférieure du noyau pour lequel ils ont été construits. Par conséquent, les modules avec des interdépendances construits pour différentes versions du noyau peuvent être interprétés comme non compatibles, et le script weak-modules ne fonctionne donc pas dans ce cas.
Pour contourner le problème, compilez ou installez les modules supplémentaires avec le dernier noyau stocké avant d'installer le nouveau noyau.
(BZ#2103605)
Le service kdump ne parvient pas à créer le fichier initrd sur les systèmes IBM Z
Sur les systèmes IBM Z 64 bits, le service kdump ne parvient pas à charger le disque RAM initial (initrd) lorsque les informations de configuration liées à znet, telles que s390-subchannels, se trouvent dans un profil de connexion NetworkManager inactif. Par conséquent, le mécanisme kdump échoue avec l'erreur suivante :
dracut: Failed to set up znet kdump: mkdumprd: failed to make kdump initrd
En guise de solution de contournement, utilisez l'une des solutions suivantes :
Configurer un lien ou un pont réseau en réutilisant le profil de connexion qui contient les informations de configuration
znet:$ nmcli connection modify enc600 master bond0 slave-type bond
Copier les informations de configuration de
znetdu profil de connexion inactif vers le profil de connexion actif :Exécutez la commande
nmclipour interroger les profils de connexionNetworkManager:# nmcli connection show NAME UUID TYPE Device bridge-br0 ed391a43-bdea-4170-b8a2 bridge br0 bridge-slave-enc600 caf7f770-1e55-4126-a2f4 ethernet enc600 enc600 bc293b8d-ef1e-45f6-bad1 ethernet --
Mettre à jour le profil actif avec les informations de configuration de la connexion inactive :
#!/bin/bash inactive_connection=enc600 active_connection=bridge-slave-enc600 for name in nettype subchannels options; do field=802-3-ethernet.s390-$name val=$(nmcli --get-values "$field"connection show "$inactive_connection") nmcli connection modify "$active_connection" "$field" $val" done
Redémarrez le service
kdumppour que les modifications soient prises en compte :# kdumpctl restart
Le mécanisme kdump ne parvient pas à capturer le fichier vmcore sur les cibles chiffrées par LUKS
Lors de l'exécution de kdump sur des systèmes dotés de partitions chiffrées Linux Unified Key Setup (LUKS), les systèmes requièrent une certaine quantité de mémoire disponible. Lorsque la mémoire disponible est inférieure à la quantité de mémoire requise, le service systemd-cryptsetup ne parvient pas à monter la partition. Par conséquent, le second noyau ne parvient pas à capturer le fichier de vidage d'urgence (vmcore) sur les cibles chiffrées LUKS.
La commande kdumpctl estimate vous permet d'interroger Recommended crashkernel value, qui est la taille de mémoire recommandée pour kdump.
Pour contourner ce problème, procédez comme suit pour configurer la mémoire requise pour kdump sur les cibles cryptées LUKS :
Imprimer la valeur estimée de
crashkernel:# kdumpctl estimate
Configurez la quantité de mémoire requise en augmentant la valeur de
crashkernel:# grubby --args=crashkernel=652M --update-kernel=ALL
Redémarrez le système pour que les modifications soient prises en compte.
# reboot
Par conséquent, kdump fonctionne correctement sur les systèmes dotés de partitions chiffrées par LUKS.
(BZ#2017401)
L'allocation de la mémoire du noyau de crash échoue au démarrage
Sur certains systèmes Ampere Altra, l'allocation de la mémoire du noyau de crash pour l'utilisation de kdump échoue au démarrage lorsque la mémoire disponible est inférieure à 1 Go. Par conséquent, la commande kdumpctl ne parvient pas à démarrer le service kdump.
Pour contourner ce problème, procédez de l'une des manières suivantes :
-
Diminuez la valeur du paramètre
crashkerneld'un minimum de 240 MB pour répondre à l'exigence de taille, par exemplecrashkernel=240M. -
Utilisez l'option
crashkernel=x,highpour réserver la mémoire du noyau de crash supérieure à 4 Go pourkdump.
Par conséquent, l'allocation de mémoire au noyau de crash pour kdump n'échoue pas sur les systèmes Ampere Altra.
La fonctionnalité Delay Accounting n'affiche pas par défaut les colonnes de statistiques SWAPIN et IO%
La fonctionnalité Delayed Accounting, contrairement aux premières versions, est désactivée par défaut. Par conséquent, l'application iotop n'affiche pas les colonnes de statistiques SWAPIN et IO% et affiche l'avertissement suivant :
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%
La fonctionnalité Delay Accounting, qui utilise l'interface taskstats, fournit des statistiques sur les retards pour toutes les tâches ou threads qui appartiennent à un groupe de threads. Les retards dans l'exécution des tâches surviennent lorsqu'elles attendent qu'une ressource du noyau devienne disponible, par exemple, une tâche qui attend qu'une unité centrale soit libre pour s'exécuter. Les statistiques aident à définir la priorité de l'unité centrale d'une tâche, la priorité des entrées/sorties et les valeurs limites de rss de manière appropriée.
Pour contourner le problème, vous pouvez activer l'option de démarrage delayacct soit au moment de l'exécution, soit au moment du démarrage.
Pour activer
delayacctau moment de l'exécution, entrez :echo 1 > /proc/sys/kernel/task_delayacct
Notez que cette commande active la fonctionnalité à l'échelle du système, mais uniquement pour les tâches que vous démarrez après avoir exécuté cette commande.
Pour activer
delayacctde manière permanente au démarrage, utilisez l'une des procédures suivantes :Modifiez le fichier
/etc/sysctl.confpour remplacer les paramètres par défaut :Ajoutez l'entrée suivante au fichier
/etc/sysctl.conf:kernel.task_delayacct = 1
Pour plus d'informations, voir Comment définir les variables sysctl sur Red Hat Enterprise Linux.
- Redémarrez le système pour que les modifications soient prises en compte.
Modifiez le fichier de configuration de GRUB 2 pour remplacer les paramètres par défaut :
-
Ajouter l'option
delayacctà l'entréeGRUB _CMDLINE_LINUXdu fichier/etc/default/grub. Exécutez l'utilitaire
grub2-mkconfigpour régénérer la configuration de démarrage :# grub2-mkconfig -o /boot/grub2/grub.cfg
Pour plus d'informations, voir Comment modifier de façon permanente la ligne de commande du noyau ?
- Redémarrez le système pour que les modifications soient prises en compte.
-
Ajouter l'option
Par conséquent, l'application iotop affiche les colonnes de statistiques SWAPIN et IO%.
(BZ#2132480)
kTLS ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau
Kernel Transport Layer Security (kTLS) ne prend pas en charge le délestage de TLS 1.3 vers les cartes réseau. Par conséquent, le chiffrement logiciel est utilisé avec TLS 1.3 même lorsque les cartes réseau prennent en charge le délestage TLS. Pour contourner ce problème, désactivez TLS 1.3 si le délestage est nécessaire. Par conséquent, vous ne pouvez décharger que TLS 1.2. Lorsque TLS 1.3 est utilisé, les performances sont moindres, car TLS 1.3 ne peut pas être déchargé.
(BZ#2000616)
Le site iwl7260-firmware interrompt le Wi-Fi sur Intel Wi-Fi 6 AX200, AX210, et Lenovo ThinkPad P1 Gen 4
Après la mise à jour du pilote iwl7260-firmware ou iwl7260-wifi vers la version fournie par RHEL 8.7 et/ou RHEL 9.1 (et plus), le matériel se retrouve dans un état interne incorrect. Par conséquent, les cartes Intel Wifi 6 peuvent ne pas fonctionner et afficher le message d'erreur :
kernel: iwlwifi 0000:09:00.0: Failed to start RT ucode: -110 kernel: iwlwifi 0000:09:00.0: WRT: Collecting data: ini trigger 13 fired (delay=0ms) kernel: iwlwifi 0000:09:00.0: Failed to run INIT ucode: -110
Une solution non confirmée consiste à éteindre le système et à le rallumer. Ne pas redémarrer.
(BZ#2129288)
