9.8. 内核
当从 4k 迁移到 64k 页大小内核时，依赖内核页大小的客户应用程序可能需要更新
RHEL 与 4k 和 64k 页大小内核都兼容。当从 4k 迁移到 64k 页大小内核时，依赖 4k 内核页大小的客户应用程序可能需要更新。已知的实例包括 jemalloc 和依赖的应用程序。
jemalloc 内存分配器库对系统运行时环境中使用的页大小敏感。库可以构建成与 4k 和 64k 页大小内核兼容，例如，当使用 --with-lg-page=16 或 env JEMALLOC_SYS_WITH_LG_PAGE=16 配置时（用于 jemallocator Rust crate）。因此，运行时环境的页大小与编译依赖于 jemalloc 的二进制文件时出现的页大小之间可能会出现不匹配。因此，使用基于 jemalloc 的应用程序会触发以下错误：
<jemalloc>: Unsupported system page size
要避免这个问题，请使用以下方法之一：
- 使用合适的构建配置或环境选项来创建 4k 和 64k 页大小兼容二进制文件。
-
在引导到最后的 64k 内核和运行时环境后，构建任何使用
jemalloc的用户空间软件包。
例如，您可以构建 fd-find 工具，该工具也通过 cargo Rust 软件包管理器使用 jemalloc。在最后的 64k 环境中，输入 cargo 命令触发所有依赖项的新构建，以解决页大小中的不匹配：
# cargo install fd-find --force
Bugzilla:2167783[1]
使用 dnf 升级到最新的实时内核不会并行安装多个内核版本
使用 dnf 软件包管理器安装最新的实时内核需要解决软件包依赖，来同时保留新的和当前的内核版本。默认情况下，dnf 在升级过程中删除旧的 kernel-rt 软件包。
作为临时解决方案，将当前的 kernel-rt 软件包添加到 /etc/yum.conf 配置文件中的 installonlypkgs 选项中，例如 installonlypkgs=kernel-rt。
installonlypkgs 选项将 kernel-rt 附加到 dnf 使用的默认列表中。installonlypkgs 指令中列出的软件包不会被自动删除，因此支持多个内核版本来同时安装。
请注意，安装了多个内核是一种在使用新内核版本时具有回退选项的方法。
Bugzilla:2181571[1]
默认情况下，Delay Accounting 功能不会显示 SWAPIN 和 IO% 统计列
Delayed Accounting 功能与早期版本不同，它们会被默认禁用。因此，iotop 应用程序不显示 SWAPIN 和 IO% 统计列，并显示以下警告：
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%
Delay Account 功能使用 taskstats 接口，为属于线程组的所有任务或线程提供延迟统计。当任务等待 kernel 资源可用时，会延迟执行，例如：等待空闲 CPU 运行的任务。统计有助于设置任务的 CPU 优先级、I/O 优先级和 rss 限制值。
作为临时解决方案，您可以在运行时或引导时启用 delayacct 引导选项。
要在运行时启用
delayacct，请输入：echo 1 > /proc/sys/kernel/task_delayacct
请注意，这个命令可启用系统范围功能，但只适用于您在运行此命令后启动的任务。
要在引导时永久启用
delayacct，请使用以下步骤之一：编辑
/etc/sysctl.conf文件以覆盖默认参数：在
/etc/sysctl.conf文件中添加以下条目：kernel.task_delayacct = 1
如需更多信息，请参阅 如何在 Red Hat Enterprise Linux 上设置 sysctl 变量。
- 重启系统以使更改生效。
在内核命令行中添加
delayacct选项。如需更多信息，请参阅 配置内核命令行参数。
因此，iotop 应用程序会显示 SWAPIN 和 IO% 统计列。
Bugzilla:2132480[1]
具有大核数的系统上实时内核的硬件认证可能需要传递 skew-tick=1 引导参数
具有大量插槽和大核数的大型或中型系统可能会因为对 xtime_lock（其在计时系统中使用）的锁争用而遇到延迟峰值。因此，硬件认证中的延迟峰值和延迟可能会在多处理系统上发生。作为临时解决方案，您可以通过添加 skew_tick=1 引导参数，偏移每个 CPU 的计时器刻度，来在不同的时间启动。
要避免锁冲突，请启用 skew_tick=1 ：
使用
grubby启用skew_tick=1参数。# grubby --update-kernel=ALL --args="skew_tick=1"
- 重启以使更改生效。
通过显示您在启动过程中传递的内核参数来验证新设置。
cat /proc/cmdline
请注意，启用 skew_tick=1 会导致功耗的大量增加，因此只有在运行延迟敏感实时工作负载时才必须启用它。
Jira:RHEL-9318[1]
kdump 机制无法捕获 LUKS 加密目标上的 vmcore 文件
当在使用 Linux Unified Key Setup(LUKS)加密分区的系统中运行 kdump 时，系统需要特定的可用内存。当可用内存小于所需内存量时，systemd-cryptsetup 服务将无法挂载分区。因此，第二个内核无法捕获 LUKS 加密目标上的崩溃转储文件。
作为临时解决方案，查询 推荐的 crashkernel 值 ，并逐渐将内存大小增加到合适的值。推荐的 crashkernel 值 可作为设置所需内存大小的参考。
打印估计的崩溃内核值。
# kdumpctl estimate
通过增加
crashkernel值来配置所需的内存量。# grubby --args=crashkernel=652M --update-kernel=ALL
重启系统以使更改生效。
# reboot
因此，kdump 在带有 LUKS 加密分区的系统上可以正常工作。
Jira:RHEL-11196[1]
kdump 服务无法在 IBM Z 系统中构建 initrd 文件
在 64 位 IBM Z 系统中，当 znet 相关配置信息（如 s390-subchannels ）位于不活跃 NetworkManager 连接配置集时，kdump 服务无法加载初始 RAM 磁盘 (initrd)。因此，kdump 机制会失败并显示以下错误：
dracut: Failed to set up znet kdump: mkdumprd: failed to make kdump initrd
作为临时解决方案，请使用以下解决方案之一：
通过重新使用具有
znet配置信息的连接配置集来配置网络绑定或桥接：$ nmcli connection modify enc600 master bond0 slave-type bond
将
znet配置信息从不活跃连接配置集复制到活跃连接配置集中：运行
nmcli命令查询NetworkManager连接配置集：# 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 --
使用不活跃连接中的配置信息更新活跃的配置集：
#!/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
重启
kdump服务以使更改生效：# kdumpctl restart
iwl7260-firmware 破坏了 Intel Wi-Fi 6 AX200、AX210 和 Lenovo ThinkPad P1 Gen 4 上的 Wi-Fi
在将 iwl7260-firmware 或 iwl7260-wifi 驱动程序更新到 RHEL 9.1 及之后的版本提供的版本后，硬件会进入不正确的内部状态。错误地报告其状态。因此，Intel Wifi 6 卡可能无法正常工作，并显示错误信息：
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
未确认的临时解决方法是关闭系统并再次打开。不要重启。
Bugzilla:2129288[1]
kmod 中的 weak-modules 不能与模块间依赖一起工作
kmod 软件包提供的 weak-modules 脚本决定了哪些模块与安装的内核 kABI 兼容。但是，在检查模块的内核兼容性时，weak-modules 按照构建它们的内核的从高到低版本来处理模块符号依赖项。因此，针对不同内核版本构建的具有相互依赖关系的模块可能会被解释为不兼容，因此 weak-modules 脚本不能在此场景下工作。
要临时解决这个问题，请在安装新内核前针对最新的库存内核构建或放置额外的模块。
Bugzilla:2103605[1]
Intel® i40e 适配器在 IBM Power10 上永久失败
当 i40e 适配器在 IBM Power10 系统上遇到 I/O 错误时，增强的 I/O 错误处理(EEH)内核服务会触发网络驱动程序的重置和恢复。 但是，EEH 重复报告 I/O 错误，直到 i40e 驱动程序达到预定义的最大 EEH 冻结为止。因此，EEH 会导致设备永久失败。
Jira:RHEL-15404[1]
DKMS 在程序失败时提供不正确的警告，在 64 位 ARM CPU 中正确编译的驱动程序
动态内核模块支持(dkms)工具无法识别 64 位 ARM CPU 的内核标头可用于 4 KB 和 64 KB 页面大小的内核。因此，当执行内核更新且未安装 kernel-64k-devel 软件包时，dkms 会提供错误警告，为什么程序在正确编译的驱动程序中失败。要临时解决这个问题，请安装 kernel-headers 软件包，其中包含两种类型的 ARM CPU 架构的头文件，且不特定于 dkms 及其要求。
Jira:RHEL-25967[1]
