11.8. 内核


在使用 Mellanox ConnectX-5 适配器的过程中 mlx5 驱动程序失败

在以太网交换机设备驱动程序模型(switchdev)模式下,当使用设备管理的流转向(DMFS)参数和 ConnectX-5 适配器支持的硬件配置时,mlx5 驱动程序失败。因此,您可以看到以下错误信息:

BUG: Bad page cache in process umount pfn:142b4b

要临时解决这个问题,您需要使用软件管理的流 转向(SMFS)参数而不是 DMFS。

(BZ#2180665)

启用了安全引导的 fadump 可能会导致 GRUB 内存不足(OOM)

在安全引导环境中,GRUB 和 PowerVM 一起分配 512 MB 内存区域,称为 Real Mode Area (RMA),用于引导内存。区域在引导组件之间划分,如果任何一个组件超过了其分配,则会发生内存不足故障。

通常,默认安装的 initramfs 文件系统和 vmlinux 符号表在限制内,以避免出现这样的故障。但是,如果在系统中启用了固件辅助转储(FADump),则默认的 initramfs 大小可能会增加,并超过 95 MB。因此,每次系统重启都会导致 GRUB OOM 状态。

要避免这个问题,请不要将安全引导和 FA 转储一起使用。有关如临时何解决这个问题的更多信息和方法,请参阅 https://www.ibm.com/support/pages/node/6846531

(BZ#2149172)

kmod 中的 weak-modules 不能与模块间依赖一起工作

kmod 软件包提供的 weak-modules 脚本决定了哪些模块与安装的内核 kABI 兼容。但是,在检查模块的内核兼容性时,weak-modules 按照构建它们的内核的从高到低版本来处理模块符号依赖项。因此,针对不同内核版本构建的具有相互依赖关系的模块可能会被解释为不兼容,因此 weak-modules 脚本不能在此场景下工作。

要临时解决这个问题,请在安装新内核前针对最新的库存内核构建或放置额外的模块。

(BZ#2103605)

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 配置信息从不活跃连接配置集复制到活跃连接配置集中:

    1. 运行 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 --
    2. 使用不活跃连接中的配置信息更新活跃的配置集:

      #!/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
    3. 重启 kdump 服务以使更改生效:

      # kdumpctl restart

(BZ#2064708)

kdump 机制无法捕获 LUKS 加密目标上的 vmcore 文件

当在使用 Linux Unified Key Setup(LUKS)加密分区的系统中运行 kdump 时,系统需要特定的可用内存。当可用内存小于所需内存量时,systemd-cryptsetup 服务将无法挂载分区。因此,第二个内核无法在 LUKS 加密目标上捕获崩溃转储文件(vmcore)。

使用 kdumpctl estimate 命令,您可以查询 推荐的 crashkernel 值,这是 kdump 所需的内存大小。

要解决这个问题,请按照以下步骤在 LUKS 加密目标中为 kdump 配置所需的内存:

  1. 输出估计的 crashkernel 值:

    # kdumpctl estimate
  2. 通过增大 crashkernel 值来配置所需的内存量:

    # grubby --args=crashkernel=652M --update-kernel=ALL
  3. 重启系统以使更改生效。

    # reboot

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

(BZ#2017401)

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

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

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

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

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

(BZ#2065013)

默认情况下,Delay Accounting 功能不会显示 SWAPINIO% 统计列

Delayed Accounting 功能与早期版本不同,它们会被默认禁用。因此,iotop 应用程序不显示 SWAPINIO% 统计列,并显示以下警告:

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. 重启系统以使更改生效。
    • 编辑 GRUB 2 配置文件以覆盖默认参数:

      1. delayacct 选项附加到 /etc/default/grub 文件的 GRUB _CMDLINE_LINUX 条目。
      2. 运行 grub2-mkconfig 工具以重新生成引导配置:

        # grub2-mkconfig -o /boot/grub2/grub.cfg

        如需更多信息,请参阅如何永久修改内核命令行?

      3. 重启系统以使更改生效。

因此,iotop 应用程序会显示 SWAPINIO% 统计列。

(BZ#2132480)

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。

(BZ#2000616)

iwl7260-firmware 在 Intel Wi-Fi 6 AX200、AX210 和 Lenovo ThinkPad P1 Gen 4 上会破坏 Wi-Fi

在将 iwl7260-firmwareiwl7260-wifi 驱动程序更新至 RHEL 8.7 和/或 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

一个没有限制的问题是关闭该系统并重新恢复。不重启。

(BZ#2129288)

dkms 在在 64 位 ARM CPU 上,对带有正确编译的驱动程序的程序失败提供错误的警告,

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

(JIRA:RHEL-25967)

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.