11.8. 内核
内核 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。
Bugzilla:1868526
tuned-adm profile powerave
命令会导致系统变得无响应
执行 tuned-adm profile powersave
命令会导致使用旧的Thunderx(CN88x)处理器的Penguin Valkyrie 2000 2-socket 系统处于无响应状态。因此,需要重启系统以便恢复工作。要临时解决这个问题,如果您的系统符合上述说明,请避免使用 powersave
配置集。
Bugzilla:1609288
HP NMI 监视器并不总是生成崩溃转储
在某些情况下,HP NMI watchdog 的 hpwdt
驱动无法声明一个由 HPE watchdog timer 生成的不可屏蔽中断(NMI),因为 NMI 被 perfmon
驱动所消耗。
缺少的 NMI 是由以下两个条件之一引发的:
- Integrated Lights-Out (iLO) 服务器管理软件中的 Generate NMI 按钮。这个按钮由用户触发。
-
hpwdt
watchdog。默认过期会向服务器发送一个 NMI。
在系统无响应时通常会出现这两个序列。在一般情况下,用于这两种情况的 NMI 处理程序调用 kernel panic()
功能,如果配置了, kdump
服务会生成 vmcore
文件。
由于缺少 NMI,没有调用 kernel panic()
且不收集 vmcore
。
第一种情况(1.),如果系统不响应,它会一直处于这个状态。要临时解决这种情况,请使用虚拟 Power 按钮来重置或者启用服务器。
在第二个示例中(2.),缺少的 NMI 之后会在 9 秒后被自动系统恢复(ASR)重置。
HPE Gen9 服务器行以单位数字显示这个问题。Gen10 频率更小。
Bugzilla:1602962
重新加载相同的崩溃扩展可能会导致分段错误
当您加载已加载的崩溃扩展文件的副本时,可能会触发分段错误。目前,crash 工具会检测原始文件是否已被加载。因此,由于两个完全相同的文件在 crash 工具中并存,因此会发生命名空间冲突,这会触发 crash 工具,从而导致分段错误。
您可以通过只加载 crash 扩展文件一次来临时解决此问题。因此,在描述的场景中不再会出现分段错误。
将虚拟功能附加到虚拟机时连接会失败
使用传奇 ionic
设备驱动程序的 Pensando 网卡会默默地接受 VLAN 标签配置请求,并在将网络虚拟功能(VF
)附加到虚拟机(VM
)上时尝试配置网络连接。这些网络连接会失败,因为卡的固件还没有支持这个功能。
Bugzilla: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 的可替代传输层。
Bugzilla:1866402
在内存热插拔操作后,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
在上述场景中被成功保存。
Bugzilla:1793389
使用 irqpoll
会导致 vmcore
生成失败
由于在 Amazon Web Services Graviton 1 处理器上运行的 64 位 ARM 架构上的 nvme
驱动程序存在问题,因此导致在给第一个内核提供 irqpoll
内核命令行参数时 vmcore
生成失败。因此,当内核崩溃时,vmcore
文件不会在 /var/crash/
目录中转储 。要临时解决这个问题:
在
/etc/sysconfig/kdump
文件中,将irqpoll
追加到KDUMP_COMMANDLINE_REMOVE
变量中。# KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
删除
/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"
重启
kdump
服务:# systemctl restart kdump
因此,第一个内核会正确引导,在内核崩溃时可以捕获 vmcore
文件。
请注意,Amazon Web Services Graviton 2 和 Amazon Web Services Graviton 3 处理器不需要手动删除 /etc/sysconfig/kdump
文件中的 irqpoll
参数。
kdump
服务可能会使用大量崩溃内核内存来转储 vmcore
文件。确定捕获内核有足够的内存可用于 kdump
服务。
有关此已知问题的详情,请查看 irqpoll 内核命令行参数可能会导致 vmcore 生成失败 的文章。
Bugzilla:1654962
在 RHEL 8 上,调试内核无法在崩溃捕获环境中引导
由于 调试内核的内存密集型特性,当调试内核在使用,且触发了内核 panic 时会出现问题。因此,调试内核无法作为捕获内核启动,而是生成堆栈跟踪。要临时解决这个问题,请根据需要增大崩溃内核内存。因此,调试内核会在崩溃捕获环境中成功引导。
Bugzilla:1659609
在引导时分配崩溃内核内存失败
在某些 Ampere Altra 系统上,当 BIOS 设置中禁用了 32 位区域时,在引导过程中分配崩溃内核内存会失败。因此,kdump
服务无法启动。这是因为 4 GB 以下的内存碎片导致,没有足够大的碎片来包含崩溃内核内存。
要临时解决这个问题,请在 BIOS 中启用 32 位内存区域,如下所示:
- 在您的系统中打开 BIOS 设置。
- 打开 Chipset 菜单。
-
在 Memory Configuration 下,启用
SSlave 32-bit
选项。
因此,在 32 位区域中的崩溃内核内存分配会成功,kdump
服务可以按预期工作。
Bugzilla:1940674
由于网络接口名称的意外更改,IBM Z 上的 RoCE 接口丢失了其 IP 设置
在 RHEL 8.6 及更早版本中,udev
设备管理器在 IBM Z 平台上将不可预测的设备名称分配给由唯一标识符(UID)枚举的 RoCE 接口。但是,在 RHEL 8.7 及更高版本中,udev
将带有 eno
前缀的可预测设备名称分配给这些接口。
如果您从 RHEL 8.6 或更早版本更新至 8.7 或更高版本,则这些 UID 枚举的接口有新名称,且不再与 NetworkManager 连接配置文件中的设备名称匹配。因此,这些接口在更新后没有 IP 配置。
有关在更新前可以应用的临时解决方案,以及更新系统后可以应用的修复,请参阅 在升级到 RHEL 8.7 或更高版本后 IBM Z 上的 RoCE 接口丢失了其 IP 设置。
Bugzilla:2169382
QAT 管理器没有为 LKCF 保留备用设备
Intel® QuickAssist Technology (QAT)管理器(qatmgr
)是一个用户空间进程,默认情况下会使用系统中的所有 QAT 设备。因此,没有为 Linux 内核加密框架(LKCF)保留任何 QAT 设备。不需要临时解决这种情况,因为此行为是预期的,大多数用户都将使用来自用户空间的加速。
Bugzilla:1920086
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 服务器适配器用户指南
。
Bugzilla:1971506
使用 page_poison=1
可能会导致内核崩溃
当在带有错误 EFI 实现的固件上使用 page_poison=1
作为内核参数时,操作系统可能会导致内核崩溃。默认情况下,这个选项被禁用,不推荐启用它,特别是在生产系统中。
Bugzilla:2050411
iwl7260-firmware
破坏了 Intel Wi-Fi 6 AX200、AX210 和 Lenovo ThinkPad P1 Gen 4 上的 Wi-Fi
在将 iwl7260-firmware
或 iwl7260-wifi
驱动程序更新到 RHEL 8.7 及更新版本提供的版本后,硬件会进入不正确的内部状态。错误地报告其状态。因此,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:2106341
IBM Power 系统上的安全引导不支持迁移
目前在 IBM Power 系统上,在成功迁移物理卷(PV)后不会引导逻辑分区(LPAR)。因此,在分区上启用了安全引导的任何类型的自动迁移都会失败。
Bugzilla:2126777
kmod
中的 weak-modules
不能与模块间依赖一起工作
kmod
软件包提供的 weak-modules
脚本决定了哪些模块与安装的内核 kABI 兼容。但是,在检查模块的内核兼容性时,weak-modules
按照构建它们的内核的从高到低版本来处理模块符号依赖项。因此,针对不同内核版本构建的具有相互依赖关系的模块可能会被解释为不兼容,因此 weak-modules
脚本不能在此场景下工作。
要临时解决这个问题,请在安装新内核前针对最新的库存内核进行构建或放置额外的模块。
Bugzilla:2103605
Ampere Altra 服务器中的 kdump
进入 OOM 状态
Ampere Altra 和 Altra Max 服务器中的固件当前会导致内核分配太多事件、中断和命令队列,这消耗了太多内存。因此,kdump
内核进入内存不足(OOM)状态。
要临时解决这个问题,请通过将 crashkernel=
内核选项的值增加到 640M,来为 kdump
保留额外的内存。
Bugzilla:2111855
在具有大核数系统上的实时内核的硬件认证可能需要传递 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
会导致功耗的大量增加,因此只有在运行延迟敏感实时工作负载时才必须启用它。
Bugzilla:2214508