Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

10.6. 内核

某些 BCC 实用程序会显示不必要的警告

由于在某些编译器特定的内核标头中进行了宏重新定义。一些 BPF Compiler Collection（BCC）工具显示以下警告： 

warning: __no_sanitize_address' macro redefined [-Wmacro-redefined]
Copy to Clipboard Toggle word wrap

这个警告是没有损害的，可以忽略它。

(BZ#1907271)

在内存热插拔或拔出操作后，vmcore 捕获失败

执行内存 hot-plug 或 hot-unplug 操作后，会更新包含内存布局信息的设备树。因此，makedumpfile 实用程序会尝试访问不存在的物理地址。如果以下条件都满足，就会出现问题：

  • IBM Power System 的 little-endian 变体运行 RHEL 8。
  • 在系统中启用了 kdump 或者 fadump 服务。

因此，如果在内存 hot-plug 或 hot-unplug 操作后触发了内核崩溃，捕获内核将无法保存 vmcore。

要临时解决这个问题，在 hot-plug 或 hot-unplug 后重启 kdump 服务： 

# systemctl restart kdump.service
Copy to Clipboard Toggle word wrap

因此，vmcore 在上述场景中被成功保存。

(BZ#1793389)

kdump在SSH或NFS转储目标上转储vmcore会失败

新版本的 dracut-network 放了对需要 ipcalc 的 dhcp-client 的依赖。因此，当 NIC 端口配置为静态 IP ，并且kdump 配置为在 SSH 或 NFS 转储目标上进行转储，那么kdump 会失败，并显示以下错误消息： 

ipcalc: command not found
Copy to Clipboard Toggle word wrap

要临时解决这个问题：

  1. 手动安装 ipcalc 软件包。 

    dnf install ipcalc
    Copy to Clipboard Toggle word wrap

  2. 为 kdump 重新构建 initramfs。 

    kdumpctrl rebuild
    Copy to Clipboard Toggle word wrap

  3. 重启 kdump 服务。 

    systemctl restart kdump
    Copy to Clipboard Toggle word wrap

因此，kdump 在上述场景中是成功的。

(BZ#1931266)

Debug 内核无法在 RHEL 8 的崩溃捕获环境中引导

由于 debug 内核的内存需求特性，会在使用 debug 内核并触发内核 panic 时出现问题。因此，调试内核无法作为捕获内核引导，而是生成一个堆栈追踪。要临时解决这个问题，相应地增大崩溃内核内存。因此，debug 内核可以在崩溃捕获环境中成功引导。

(BZ#1659609)

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

在某些 Ampere Altra 系统中，当 BIOS 设置中禁用 32 位区域时，内存分配会失败。因此，kdump 服务无法启动，因为常规内存不够大，无法保留内存分配。

要临时解决这个问题，在 BIOS 中启用 32 位 CPU，如下所示：

  1. 在您的系统中打开 BIOS 设置。
  2. 打开 Chipset 菜单。
  3. 在 Memory Configuration 下，启用 SSlave 32-bit 选项。

因此，崩溃内核会在 32 位区域分配内存，kdump 服务可以正常工作。

（BZ#1940674）

某些内核驱动程序不显示其版本

RHEL 8.4 中更改了很多网络内核驱动程序的模块版本行为。因此，这些驱动程序现在不会显示其版本。或者，在执行 ethtool -i 命令后，驱动程序会显示 内核版本，而不是 驱动程序 版本。要临时解决这个问题，用户可以运行以下命令： 

# modinfo <AFFECTED_DRIVER> | grep rhelversion
Copy to Clipboard Toggle word wrap

因此，用户可以在需要的情况下决定受影响内核驱动程序的版本。

请注意，驱动版本字符串中预期的变化对驱动程序本身没有实际影响。

(BZ#1944639)

使用 irqpoll 会导致 vmcore 生成失败

由于在 Amazon Web Services(AWS)云平台上运行的 64 位 ARM 架构中的 nvme 驱动程序存在问题，在第一个内核提供了 irqpoll 内核命令行参数时 vmcore 生成会失败。因此，在内核崩溃后，/var/crash/ 目录中不会转储 vmcore 文件。要临时解决这个问题：

  1. 将 irqpoll 附加到/etc/sysconfig/kdump 文件中的KDUMP_COMMANDLINE_REMOVE。 

    KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
    Copy to Clipboard Toggle word wrap

  2. 从 /etc/sysconfig/kdump 文件中的 KDUMP_COMMANDLINE_APPEND 中删除 irqpoll。 

    KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd"
    Copy to Clipboard Toggle word wrap
  3. 运行 systemctl restart kdump 命令重启 kdump 服务。

因此，第一个内核会正确引导，在内核崩溃时可以捕获 vmcore 文件。

请注意，kdump 服务可能会使用大量崩溃内核内存转储 vmcore 文件。确定捕获内核有足够的内存可用于 kdump 服务。

(BZ#1654962)

HP NMI 监视器并不总是生成崩溃转储

在某些情况下，HP NMI watchdog 的 hpwdt 驱动无法声明一个由 HPE watchdog timer 生成的不可屏蔽中断（NMI），因为 NMI 被 perfmon 驱动所消耗。

缺少的 NMI 是由以下两个条件之一引发的：

  1. Integrated Lights-Out (iLO) 服务器管理软件中的 Generate NMI 按钮。这个按钮由用户触发。
  2. hpwdt watchdog。默认过期会向服务器发送一个 NMI。

在系统无响应时通常会出现这两个序列。在一般情况下，用于这两种情况的 NMI 处理程序调用 kernel panic() 功能，如果配置了, kdump 服务会生成 vmcore 文件。

由于缺少 NMI，没有调用 kernel panic() 且不收集 vmcore。

第一种情况(1.)，如果系统不响应，它会一直处于这个状态。要临时解决这种情况，请使用虚拟 Power 按钮来重置或者启用服务器。

在第二个示例中（2.），缺少的 NMI 之后会在 9 秒后被自动系统恢复（ASR）重置。

HPE Gen9 服务器行以单位数字显示这个问题。Gen10 频率更小。

(BZ#1602962)

tuned-adm profile powerave 命令会导致系统变得无响应

执行 tuned-adm profile powersave 命令会导致使用旧的Thunderx(CN88x)处理器的Penguin Valkyrie 2000 2-socket 系统处于无响应状态。因此，需要重启系统以便恢复工作。要临时解决这个问题，如果您的系统符合上述说明，请避免使用 powersave 配置集。

(BZ#1609288)

内核 ACPI 驱动程序报告无法访问 PCIe ECAM 内存区域

固件提供的高级配置和电源接口（ACPI）表没有在 PCI 总线设备中定义内存区域。因此，在系统引导时会出现以下警告信息： 

[    2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace
[    2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]
Copy to Clipboard Toggle word wrap

但是，内核仍然可以访问 0x30000000-0x31ffff 内存区域，并可以正确地将该内存区域分配给 PCI 增强配置访问机制(ECAM)。您可以通过以下输出通过 256 字节偏移访问 PCIe 配置空间来验证 PCI 是正常工作的： 

03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
 ...
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=0us LTR1.2_Threshold=0ns
                L1SubCtl2: T_PwrOn=10us
Copy to Clipboard Toggle word wrap

因此，您可以忽略警告信息。

有关此问题的详情，请参阅 "Firmware Bug: ECAM area mem 0x30000000-0x31ffffff not reserved in ACPI namespace" appears during system boot。

(BZ#1868526)

带有默认设置的 hwloc 命令在单个 CPU Power9 和 Power10 LPAR 上无法正常工作

对于 2.2.0 版本的 hwloc 软件包，任何运行 Power9 / Power10 CPU 的单节点Non-Uniform Memory Access(NUMA)系统都被视为"禁用"。因此, all hwloc 命令都无法正常工作，并会显示以下错误信息： 

Topology does not contain any NUMA node, aborting!
Copy to Clipboard Toggle word wrap

您可以使用这两个选项之一来解决这个问题：

  • 设置环境变量 HWLOC_ALLOW=all
  • 在各种 hwloc 命令中使用 disallowed 标志

因此，hwloc 命令不会在上述场景中返回任何错误。

（BZ#1917560）

OPEN MPI 库可能会使用默认 PML 的触发程序运行时失败

在 OPEN 消息密码界面（OPEN MPI）实现 4.0.x 系列中，Unified communicating X（UCX）是默认的点到点通信器（PML）。OPEN MPI 4.0.x 系列的后续版本弃用了 openib Byte Transfer Layer(BTL)。

但是，当OPEN MPI 在 同构 集群（与硬件和软件配置相同）上运行时，UCX 仍然使用openib BTL进行 MPI 单边操作。因此，这可能会导致触发器执行错误。要临时解决这个问题：

  • 使用以下参数运行 mpirun 命令： 
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0
Copy to Clipboard Toggle word wrap

其中,

  • -mca btl openib 参数禁用 openib BTL
  • -mca pml ucx 参数将 OPEN MPI 配置为使用 ucx PML。
  • x UCX_NET_DEVICES= 参数限制 UCX 使用指定的设备

OPEN MPI 在使用 异构 集群（不同硬件和软件配置）中运行时，使用 UCX 作为默认的 PML。因此，这可能会导致 OPEN MPI 任务在运行时出现错误的性能、不响应性行为或崩溃问题。要临时解决这个问题，将 UCX 优先级设置为：

  • 使用以下参数运行 mpirun 命令： 
-mca pml_ucx_priority 5
Copy to Clipboard Toggle word wrap

因此，OPEN MPI 库可以选择使用 UCX 的可替代传输层。

(BZ#1866402)

将虚拟功能附加到虚拟机时连接会失败

使用传奇 ionic设备驱动程序的 Pensando 网卡会默默地接受 VLAN 标签配置请求，并在将网络虚拟功能(VF)附加到虚拟机(VM)上时尝试配置网络连接。这些网络连接会失败，因为卡的固件还没有支持这个功能。

(BZ#1930576)

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat