Menu Close

10.8. 内核

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

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

您可以通过只载入崩溃扩展文件一次来解决这个问题。因此，在上述场景中不再会出现分段错误。

(BZ#1906482)

在内存热插拔或拔出操作后 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

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

(BZ#1793389)

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

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

(BZ#1659609)

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

在特定的 Ampere Altra 系统中，当在 BIOS 设置中禁用 32 位区域时，在启动期间分配崩溃内核内存会失败。因此，k dump 服务无法启动。这是因为区域内存碎片低于 4 GB，且没有足够大的片段来容纳崩溃内核内存。

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

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

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

（BZ#1940674）

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

在有些 KVM 虚拟机上，当为 kdump 使用默认内存捕获内核崩溃转储时 ， kdump 会失败。因此，崩溃内核显示以下错误： 

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

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

如果是 crashkernel=auto 参数，则为：

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

    echo $(($(cat /sys/kernel/kexec_crash_size)/1048576+32))M
  2. 将内核 crashkernel 参数配置为 崩溃kernel=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 错误：在系统引导 解决方案中，M 区域 mem 0x30000000-0x31ffffff 未保留在 ACPI 命名空间中"。

(BZ#1868526)

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

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

(BZ#1609288)

使用 irqpoll 会导致 vmcore 生成失败

由于在 Amazon Web Services(AWS)云平台上运行的 64 位 ARM 架构中的 thenvme 驱动程序 存在问题，当您向第一个内核提供 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 仍会为 MPI 单边操作使用 openib BTL。因此，这可能会导致触发器执行错误。要临时解决这个问题：

  • 使用以下参数运行 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 Server Adapter 用户指南。

(BZ#1971506)