11.7. 内核
内核中的 kdump
机制会引起 64K 内核的 OOM
错误
64 位 ARM 架构上的 64K 内核页大小使用的内存比 4KB 内核使用的多。因此,kdump
会导致内核 panic,内存分配失败,并报内存不足(OOM)错误。作为临时解决方案,手动将 crashkernel
的值配为 640 MB。例如,将 crashkernel=
参数设为 crashkernel=2G- :640M
。
因此,kdump
机制对上述场景的 64K 内核不会失败。
Bugzilla:2160676
当从 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
<jemalloc>: Unsupported system page size
要避免这个问题,请使用以下方法之一:
- 使用合适的构建配置或环境选项来创建 4k 和 64k 页大小兼容二进制文件。
-
在引导到最终的 64k 内核和运行时环境后,构建任何使用
jemalloc
的用户空间软件包。
例如,您可以构建 fd-find
工具,该工具也通过 cargo
Rust 软件包管理器使用 jemalloc
。在最后的 64k 环境中,输入 cargo
命令触发所有依赖项的新构建,以解决页大小中的不匹配:
cargo install fd-find --force
# cargo install fd-find --force
Bugzilla:2167783
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
dracut: Failed to set up znet
kdump: mkdumprd: failed to make kdump initrd
作为临时解决方案,请使用以下解决方案之一:
通过重新使用具有
znet
配置信息的连接配置集来配置网络绑定或桥接:nmcli connection modify enc600 master bond0 slave-type bond
$ nmcli connection modify enc600 master bond0 slave-type bond
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
znet
配置信息从不活跃连接配置集复制到活跃连接配置集中:运行
nmcli
命令查询NetworkManager
连接配置集:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用不活跃连接中的配置信息更新活跃的配置集:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重启
kdump
服务以使更改生效:kdumpctl restart
# kdumpctl restart
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
KTLS 不支持将 TLS 1.3 卸载到 NIC
内核传输层安全(kTLS)不支持将 TLS 1.3 卸载到 NIC。因此,即使 NIC 支持 TLS 卸载,软件加密也会与 TLS 1.3 一起使用。要临时解决这个问题,如果需要卸载,禁用 TLS 1.3。因此,您只能卸载 TLS 1.2。当使用 TLS 1.3 时,性能较低,因为无法卸载 TLS 1.3。
Bugzilla:2000616
默认情况下,Delay Accounting
功能不会显示 SWAPIN
和 IO%
统计列
Delayed Accounting
功能与早期版本不同,它们会被默认禁用。因此,iotop
应用程序不显示 SWAPIN
和 IO%
统计列,并显示以下警告:
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and 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
echo 1 > /proc/sys/kernel/task_delayacct
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 请注意,这个命令可启用系统范围功能,但只适用于您在运行此命令后启动的任务。
要在引导时永久启用
delayacct
,请使用以下步骤之一:编辑
/etc/sysctl.conf
文件以覆盖默认参数:在
/etc/sysctl.conf
文件中添加以下条目:kernel.task_delayacct = 1
kernel.task_delayacct = 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如需更多信息,请参阅 如何在 Red Hat Enterprise Linux 上设置 sysctl 变量。
- 重启系统以使更改生效。
在内核命令行中添加
delayacct
选项。如需更多信息,请参阅 配置内核命令行参数。
因此,iotop
应用程序会显示 SWAPIN
和 IO%
统计列。
Bugzilla:2132480
kdump
机制无法捕获 LUKS 加密目标上的 vmcore
文件
当在使用 Linux Unified Key Setup(LUKS)加密分区的系统中运行 kdump
时,系统需要特定的可用内存。当可用内存小于所需内存量时,systemd-cryptsetup
服务将无法挂载分区。因此,第二个内核无法捕获 LUKS 加密目标上的崩溃转储文件(vmcore
)。
使用 kdumpctl estimate
命令,您可以查询 推荐的 crashkernel 值
,这是 kdump
所需的内存大小。
要解决这个问题,请按照以下步骤在 LUKS 加密目标中为 kdump
配置所需的内存:
输出估计的
crashkernel
值:kdumpctl estimate
# kdumpctl estimate
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过增大
crashkernel
值来配置所需的内存量:grubby --args=crashkernel=652M --update-kernel=ALL
# grubby --args=crashkernel=652M --update-kernel=ALL
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重启系统以使更改生效。
reboot
# reboot
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
因此,kdump
在带有 LUKS 加密分区的系统上可以正常工作。
Bugzilla:2017401
在引导时分配崩溃内核内存失败
在某些 Ampere Altra 系统中,在可用内存低于 1GB 时为 kdump
分配崩溃内核内存会失败。因此,kdumpctl
命令无法启动 kdump
服务。
要解决这个问题,请执行以下操作之一:
-
减少
crashkernel
参数的值(最少 240 MB)以满足大小要求,例如crashkernel=240M
)。 -
使用
crashkernel=x,high
选项为kdump
保留大于 4 GB 的崩溃内核内存。
因此,kdump
的崩溃内核内存分配不会在 Ampere Altra 系统上失败。
启用 VMD 时,RHEL 无法识别 NVMe 磁盘
当您重置或重新附加驱动程序时,卷组管理设备(VMD)域目前不会软重置。因此,硬件无法正确检测并枚举其设备。因此,启用了 VMD 的操作系统无法识别 NVMe 磁盘,特别是在重置服务器或使用虚拟机时。
Bugzilla:2128610
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
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
kmod
中的 weak-modules
不能与模块间依赖一起工作
kmod
软件包提供的 weak-modules
脚本决定了哪些模块与安装的内核 kABI 兼容。但是,在检查模块的内核兼容性时,weak-modules
按照构建它们的内核的从高到低版本来处理模块符号依赖项。因此,针对不同内核版本构建的具有相互依赖关系的模块可能会被解释为不兼容,因此 weak-modules
脚本不能在此场景下工作。
要临时解决这个问题,请在安装新内核前针对最新的库存内核进行构建或放置额外的模块。
Bugzilla:2103605
使用 Mellanox ConnectX-5
适配器时,mlx5
驱动程序会失败
在以太网交换机设备驱动程序型号(switchdev
)模式下,当使用设备管理的流控制(DMFS)参数和 ConnectX-5
适配器支持的硬件配置时,mlx5
驱动程序会失败。因此,您可以看到以下错误信息:
BUG: Bad page cache in process umount pfn:142b4b
BUG: Bad page cache in process umount pfn:142b4b
要临时解决这个问题,请使用软件管理的流控制 (SMFS)参数,而不是 DMFS。
Bugzilla:2180665
在具有大量核数的系统上实时内核的硬件认证可能需要传递 skew-tick=1
引导参数来避免锁争用
具有大量插槽和大核数的大型或中型系统可能会因为对 xtime_lock
(其在计时系统中使用)的锁争用而遇到延迟峰值。因此,硬件认证中的延迟峰值和延迟可能会在多处理系统上发生。作为临时解决方案,您可以通过添加 skew_tick=1
引导参数,偏移每个 CPU 的计时器刻度,来在不同的时间启动。
要避免锁冲突,请启用 skew_tick=1
:
使用
grubby
启用skew_tick=1
参数。grubby --update-kernel=ALL --args="skew_tick=1"
# grubby --update-kernel=ALL --args="skew_tick=1"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 重启以使更改生效。
-
运行
cat /proc/cmdline
命令来验证新设置。
请注意,启用 skew_tick=1
会导致功耗的大量增加,因此只有在运行延迟敏感实时工作负载时才必须启用它。
Bugzilla:2214508
DKMS
对 64 位 ARM CPU 上正确编译的驱动程序提供一条不正确的程序失败警告
动态内核模块支持(dkms
)工具无法识别适用于 4 KB 和 64 KB 页大小内核的 64 位 ARM CPU 的内核头文件。因此,当执行了内核更新,且 kernel-64k-devel
软件包未安装时,dkms
会提供一条有关为什么程序在正确编译的驱动程序上失败的错误警告。要临时解决这个问题,请安装 kernel-headers
软件包,其包含两种类型的 ARM CPU 架构的头文件,且不特定于 dkms
及其要求。
Jira:RHEL-25967