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

要避免这个问题，请使用以下方法之一：

使用合适的构建配置或环境选项来创建 4k 和 64k 页大小兼容二进制文件。
在引导到最终的 64k 内核和运行时环境后，构建任何使用 jemalloc 的用户空间软件包。

例如，您可以构建 fd-find 工具，该工具也通过 cargo Rust 软件包管理器使用 jemalloc。在最后的 64k 环境中，输入 cargo 命令触发所有依赖项的新构建，以解决页大小中的不匹配：

# 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

作为临时解决方案，请使用以下解决方案之一：

通过重新使用具有 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
```

Bugzilla:2064708

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%

Delay Account 功能使用 taskstats 接口，为属于线程组的所有任务或线程提供延迟统计。当任务等待 kernel 资源可用时，会延迟执行，例如：等待空闲 CPU 运行的任务。统计有助于设置任务的 CPU 优先级、I/O 优先级和 rss 限制值。

作为临时解决方案，您可以在运行时或引导时启用 delayacct 引导选项。

要在运行时启用 delayacct，请输入：
```
echo 1 > /proc/sys/kernel/task_delayacct
```
请注意，这个命令可启用系统范围功能，但只适用于您在运行此命令后启动的任务。
要在引导时永久启用 delayacct，请使用以下步骤之一：
- 编辑 /etc/sysctl.conf 文件以覆盖默认参数：
  1. 在 /etc/sysctl.conf 文件中添加以下条目：
    
    kernel.task_delayacct = 1
    
    如需更多信息，请参阅如何在 Red Hat Enterprise Linux 上设置 sysctl 变量。
  2. 重启系统以使更改生效。
- 在内核命令行中添加 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
```
通过增大 crashkernel 值来配置所需的内存量：
```
# grubby --args=crashkernel=652M --update-kernel=ALL
```
重启系统以使更改生效。
```
# reboot
```

因此，kdump 在带有 LUKS 加密分区的系统上可以正常工作。

Bugzilla:2017401

在引导时分配崩溃内核内存失败

在某些 Ampere Altra 系统中，在可用内存低于 1GB 时为 kdump 分配崩溃内核内存会失败。因此，kdumpctl 命令无法启动 kdump 服务。

要解决这个问题，请执行以下操作之一：

减少 crashkernel 参数的值（最少 240 MB）以满足大小要求，例如 crashkernel=240M）。
使用 crashkernel=x,high 选项为 kdump 保留大于 4 GB 的崩溃内核内存。

因此，kdump 的崩溃内核内存分配不会在 Ampere Altra 系统上失败。

Bugzilla:2065013

启用 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

一个没有确认的临时解决方法是关闭并再次打开系统。不要重启。

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

要临时解决这个问题，请使用软件管理的流控制 (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"

重启以使更改生效。
运行 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

11.7. 内核

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links