11.8. 内核

内核中的 kdump 机制会引起 64K 内核的 OOM 错误

64 位 ARM 架构上的 64K 内核页大小使用的内存比 4KB 内核使用的多。因此，kdump 会导致内核 panic，内存分配失败，并报内存不足(OOM)错误。作为临时解决方案，手动将 crashkernel 的值配为 640 MB。例如，将 crashkernel= 参数设为 crashkernel=2G- :640M。

因此，kdump 机制对上述场景的 64K 内核不会失败。

Bugzilla:2160676^[1]

当从 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 文件以覆盖默认参数：
  1. 在 /etc/sysctl.conf 文件中添加以下条目：
    kernel.task_delayacct = 1
    如需更多信息，请参阅如何在 Red Hat Enterprise Linux 上设置 sysctl 变量。
  2. 重启系统以使更改生效。
- 在内核命令行中添加 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
```

Bugzilla:2064708

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]

dkms 对 64 位 ARM CPU 上正确编译的驱动程序提供了一条有关程序失败的不正确的警告

动态内核模块支持(dkms)工具无法识别用于 4 KB 内核和 64 KB 页大小的内核 64 位 ARM CPU 的内核标头。因此，当执行内核更新且 kernel-64k-devel 软件包未安装时，dkms 会提供一条有关为什么程序在正确编译的驱动程序上失败的错误警告。要临时解决这个问题，请安装 kernel-headers 软件包，其包含两种类型的 ARM CPU 架构的头文件，且不特定于 dkms 及其要求。

JIRA:RHEL-25967^[1]

11.8. 内核

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links