10.8. 内核


重新加载相同的崩溃扩展可能会导致分段错误

当您加载已加载的崩溃扩展文件的副本时,可能会触发分段错误。目前,crash 工具会检测原始文件是否已被加载。因此,由于两个完全相同的文件在 crash 工具中并存,因此会发生命名空间冲突,这会触发 crash 工具,从而导致分段错误。

您可以通过只加载 crash 扩展文件一次来临时解决此问题。因此,在描述的场景中不再会出现分段错误。

(BZ#1906482)

在内存热插拔操作后,vmcore 捕获失败

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

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

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

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

# systemctl restart kdump.service

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

(BZ#1793389)

在 RHEL 8 上,调试内核无法在崩溃捕获环境中引导

由于 调试内核的内存密集型特性,当调试内核在使用,且触发了内核 panic 时会出现问题。因此,调试内核无法作为捕获内核引导,而是生成一个堆栈追踪。要临时解决这个问题,请根据需要增大崩溃内核内存。因此,调试内核会在崩溃捕获环境中成功引导。

(BZ#1659609)

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

在某些 Ampere Altra 系统上,当 BIOS 设置中禁用了 32 位区域时,在引导过程中分配崩溃内核内存会失败。因此,kdump 服务无法启动。这是因为 4 GB 以下的内存碎片导致,没有足够大的碎片来包含崩溃内核内存。

要临时解决这个问题,请在 BIOS 中启用 32 位内存区域,如下所示:

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

因此,在 32 位区域中的崩溃内核内存分配会成功,kdump 服务可以按预期工作。

(BZ#1940674)

kdump 在一些使用默认崩溃内核内存的 KVM 虚拟机上失败

在使用 kdump 的默认内存量来捕获内核崩溃转储时,有些 KVM 虚拟机 kdump 会失败。因此,崩溃内核会显示以下错误:

/bin/sh: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory

要临时解决这个问题,请至少增加 32M 的 crashkernel= 选项,以满足 kdump 的大小要求。例如,最终值必须是当前值和 32M 的总和。

对于 crashkernel=auto 参数:

  1. 检查当前内存大小,并将大小增加到 32M,如下所示:

    echo $(($(cat /sys/kernel/kexec_crash_size)/1048576+32))M
  2. 将内核 crashkernel 参数配置为 crashkernel=x,其中 x 是增大的大小。

(BZ#2004000)

QAT 管理器没有为 LKCF 保留备用设备

Intel® QuickAssist Technology (QAT)管理器(qatmgr)是一个用户空间进程,默认情况下会使用系统中的所有 QAT 设备。因此,没有为 Linux 内核加密框架(LKCF)保留任何 QAT 设备。不需要临时解决这种情况,因为此行为是预期的,大多数用户都将使用来自用户空间的加速。

(BZ#1920086)

内核 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]

但是,内核仍然可以访问 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

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

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

(BZ#1868526)

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

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

(BZ#1609288)

使用 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"
  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"
  3. 重启 kdump 服务:

    systemctl restart kdump

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

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

有关这个已知问题的详情,请查看文章 irqpoll 内核命令行参数可能会导致 vmcore 生成失败

(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)

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

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

(BZ#1930576)

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

其中,

  • -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

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

(BZ#1866402)

Solarflare 无法创建最大数量的虚拟函数(VF)

因为资源不足,Solarflare NIC 无法创建最大数量的 VF 。您可以检查 PCIe 设备可以在 /sys/bus/pci/devices/PCI_ID/sriov_totalvfs 文件中创建的 VF 的最大数量。要临时解决这个问题,您可以将 VF 的数量或 VF MSI 中断值调整为较低的值,可以在启动时从 Solarflare Boot Manager 调整或使用 Solarflare sfboot 工具调整。默认的 VF MSI 中断值为 8

  • 要使用 sfboot 调整 VF MSI 中断值:
# sfboot vf-msix-limit=2
注意

调整 VF MSI 中断值会影响 VF 性能。

有关调整的参数的更多信息,请参阅 Solarflare 服务器适配器用户指南

(BZ#1971506)

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.