11.7. Noyau
Le mécanisme kdump dans le noyau provoque des erreurs OOM sur le noyau 64K
La taille de page du noyau de 64 Ko sur l'architecture ARM 64 bits utilise plus de mémoire que le noyau de 4 Ko. Par conséquent, kdump provoque une panique du noyau et l'allocation de mémoire échoue avec des erreurs de type "out of memory" (OOM). Pour contourner le problème, configurez manuellement la valeur de crashkernel à 640 Mo. Par exemple, définissez le paramètre crashkernel= comme crashkernel=2G- :640M.
Par conséquent, le mécanisme kdump n'échoue pas sur le noyau 64K dans le scénario décrit.
Bugzilla:2160676
Les applications clients qui dépendent de la taille de page du noyau peuvent nécessiter une mise à jour lors du passage d'un noyau de 4k à 64k pages
RHEL est compatible avec les noyaux de taille de page 4k et 64k. Les applications clients qui dépendent d'un noyau de 4k peuvent nécessiter une mise à jour lors du passage d'un noyau de 4k à un noyau de 64k. Parmi les cas connus, citons jemalloc et les applications dépendantes.
La bibliothèque d'allocation de mémoire jemalloc est sensible à la taille de page utilisée dans l'environnement d'exécution du système. La bibliothèque peut être construite pour être compatible avec des noyaux de 4k et 64k pages, par exemple, lorsqu'elle est configurée avec --with-lg-page=16 ou env JEMALLOC_SYS_WITH_LG_PAGE=16 (pour jemallocator Rust crate). Par conséquent, un décalage peut se produire entre la taille de page de l'environnement d'exécution et la taille de page qui était présente lors de la compilation des binaires qui dépendent de jemalloc. Par conséquent, l'utilisation d'une application basée sur jemalloc déclenche l'erreur suivante :
<jemalloc> : Taille de page système non supportée
Pour éviter ce problème, utilisez l'une des approches suivantes :
- Utilisez la configuration de construction ou les options d'environnement appropriées pour créer des binaires compatibles avec les tailles de page 4k et 64k.
-
Construire tous les paquets de l'espace utilisateur qui utilisent
jemallocaprès avoir démarré dans le noyau final de 64k et l'environnement d'exécution.
Par exemple, vous pouvez construire l'outil fd-find, qui utilise également jemalloc, avec le gestionnaire de paquets Rust cargo. Dans l'environnement 64k final, déclenchez une nouvelle compilation de toutes les dépendances pour résoudre le problème de taille de page en entrant la commande cargo:
# cargo install fd-find --force
Bugzilla:2167783
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
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é.
Bugzilla:2000616
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.
Ajouter l'option
delayacctà la ligne de commande du noyau.Pour plus d'informations, voir Configuration des paramètres de la ligne de commande du noyau.
Par conséquent, l'application iotop affiche les colonnes de statistiques SWAPIN et IO%.
Bugzilla:2132480
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.
Bugzilla: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.
RHEL ne reconnaît pas les disques NVMe lorsque VMD est activé
Lorsque vous réinitialisez ou rattachez le pilote, le domaine Volume Management Device (VMD) ne se réinitialise pas en douceur. Par conséquent, le matériel ne peut pas détecter et énumérer correctement ses périphériques. Par conséquent, le système d'exploitation avec VMD activé ne reconnaît pas les disques NVMe, en particulier lors de la réinitialisation d'un serveur ou de l'utilisation d'une machine virtuelle.
Bugzilla:2128610
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 9.1 et plus, le matériel se retrouve dans un état interne incorrect et signale son état de manière incorrecte. 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.
Bugzilla:2129288
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.
Bugzilla:2103605
Le pilote mlx5 échoue lors de l'utilisation de l'adaptateur Mellanox ConnectX-5
En mode de pilote de commutateur Ethernet (switchdev), le pilote mlx5 échoue lorsqu'il est configuré avec le paramètre DMFS (device managed flow steering) et le matériel pris en charge par l'adaptateur ConnectX-5. 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, utilisez le paramètre SMFS (software managed flow steering) au lieu de DMFS.
Bugzilla:2180665
