8.5. 内核
RHEL 7 虚拟机有时无法在 ESXi 5.5 上引导
当在 VMware ESXi 5.5 hypervisor 上运行带有 12 GB RAM 或更高版本的 Red Hat Enterprise Linux 7 客户机时，某些组件目前使用不正确的内存类型范围寄存器(MTRR)值初始化，或者错误地重新配置 MTRR 值。这有时会导致客户机内核在引导过程中出现问题或客户机变得无响应。
要临时解决这个问题，请在客户机的内核命令行中添加 disable_mtrr_trim 选项，该选项可让客户机在配置 MTRR 时继续引导。请注意，使用这个选项，客户机会在引导过程中打印 WARNING: BIOS 错误信息，您可以安全地忽略它。
(BZ#1429792)
某些 NIC 固件可能会变得无响应，使用 bnx2x
由于预引导驱动程序卸载序列中的一个错误，一些互联网适配器的固件在 bnx2x 驱动程序接管设备后可能会变得无响应。bnx2x 驱动程序检测到问题，并在内核日志中返回"storm stats not not update for 3 times"。要临时解决这个问题，请应用您的硬件供应商提供的最新 NIC 固件更新。因此，卸载预引导固件现在可以正常工作，固件在 bnx2x 接管设备后不再挂起。
(BZ#1315400)
i40iw 模块不会在引导时自动载入
有些 i40e NIC 不支持 iWarp，i40iw 模块不支持挂起和恢复操作。因此，默认不会自动加载 i40iw 模块，以确保挂起和恢复操作正常工作。要临时解决这个问题，请编辑 /lib/udev/rules.d/90-rdma-hw-modules.rules 文件，以启用 i40iw 的自动负载。
另请注意，如果同一机器上安装了另一个 RDMA 设备，非i40e RDMA 设备会触发 rdma 服务，它会加载所有启用的 RDMA 堆栈模块，包括 i40iw 模块。
(BZ#1622413)
非中间持久内存配置无法使用存储
在以前的版本中，具有持久性内存的系统与 64 MB 边界一致，无法创建命名空间。因此，在某些情况下，非中断的持久内存配置无法使用存储。要临时解决这个问题，请将交集模式用于持久内存。但是，大多数存储都可用于使用，但存在有限的故障隔离。
(BZ#1691868)
系统引导可能会因为持久内存文件系统而失败
有大量持久内存的系统需要很长时间才能引导。如果 /etc/fstab 文件配置持久内存文件系统，系统可能会超时等待设备可用。然后引导过程会失败，并给出一个紧急提示符。
要临时解决这个问题，增大 /etc/systemd/system.conf 文件中的 DefaultTimeoutStartSec 值。使用足够大的值，如 1200s。因此，系统引导不会超时。
(BZ#1666535)
radeon 无法正确重置硬件
radeon 内核驱动程序目前没有在 kexec 上下文中正确重置硬件。相反，rade on 会意外终止，这会导致剩余的 kdump 服务失败。
要临时解决这个问题，请通过在 /etc/ kdump.conf 文件中添加以下行将 kdump 中的 radeon 列入黑名单：
dracut_args --omit-drivers "radeon"
之后，重启机器和 kdump。
请注意，在这种情况下，kdump 不会提供图形界面，但 kdump 可以成功完成。
(BZ#1509444)
某些 eBPF 工具可能会导致系统在 IBM Z 上变得无响应
由于 JIT 编译器中的一个错误，在 IBM Z 上的 bcc-tools 软件包中运行的某些 eBPF 工具可能会导致系统变得无响应。要临时解决这个问题，请避免使用 IBM Z 上的 bcc-tools 中的 dcsnoop、runqlen 和 slabratetop 工具，直到发布修复为止。
(BZ#1724027)
/dev/sg 中的并发 SG_IO 请求可能会导致数据崩溃
/dev/sg 设备驱动程序缺少内核数据的同步。驱动程序中的并发请求同时访问同一数据。
因此，ioctl 系统调用有时可能会错误地将 SG_IO 请求有效负载用于与正确的命令同时发送的不同命令。在某些情况下可能会导致磁盘崩溃。红帽在 Red Hat Virtualization (RHV)中发现了这个程序错误。
要临时解决这个问题，请使用以下解决方案之一：
-
不要将并发请求发送到
/dev/sg驱动程序。因此，发送到/dev/sg的每个SG_IO请求都可以保证使用正确的数据。 -
或者，使用
/dev/sd或/dev/bsg驱动程序，而不是/dev/sg。这些驱动程序中没有这个错误。
(BZ#1710533)
内部 VLAN 标签和外部 VLAN 标签的顺序不正确
在使用 mlx5 驱动程序时，系统会按照交换顺序接收内部和外部 VLAN 标签(IEEE802.1Q （IEEE802.1Q 标准)。这是因为 rxvlan 卸载开关无法在此路径中有效，并导致 Open vSwitch (OVS)推送此错误转发。没有已知的临时解决方案。
(BZ#1701502)
kdump 在 RHEL 7 中的 Azure 实例上无法生成 vmcore
通过 UEFI 引导装载程序引导的 Azure 实例上的串行控制台实现的底层问题会导致 kdump 内核无法引导。因此，崩溃内核的 vmcore 无法捕获在 /var/crash/ 目录中。要临时解决这个问题：
-
将
console=ttyS0和earlyprintk=ttyS0参数添加到/etc/sysconfig/kdump目录中的KDUMP_COMMANDLINE_REMOVE命令行。 -
重启
kdump服务。
因此，kdump 内核应该正确引导，并预期在崩溃时捕获 vmcore。
确保 /var/crash/ 中有足够的空间来保存 vmcore，这可能最多为系统内存大小。
(BZ#1724993)
如果启用了 KASLR，kdumpctl 服务将无法加载崩溃内核
kptr_restrict 内核可调整内核的不正确地设置会导致 /proc/kcore 文件的内容作为所有零生成。因此，kdumpctl 服务无法访问 /proc/kcore，并在启用了内核地址空间布局(KASLR)时加载崩溃内核。要临时解决这个问题，请将 kptr_restrict 设置为 1。因此，kdumpctl 可以在上述场景中载入崩溃内核。
详情请查看 /usr/share/doc/kexec-tools/kexec-kdump-howto.txt 文件。
(BZ#1600148)
kdump 在第二个内核中失败
kdump initramfs 归档是捕获崩溃转储的关键组件。但是，它严格会为其上运行的机器生成，且没有一般性。如果您进行磁盘迁移或安装了带有磁盘镜像的新机器，kdump 会在第二个内核中失败。
要临时解决这个问题，如果您进行磁盘迁移，请运行以下命令来手动重建 initramfs ：
# touch /etc/kdump.conf # kdumpctl restart
如果您要为安装新机器创建磁盘镜像，强烈建议不要在磁盘镜像中包含 kdump initramfs。它有助于节省空间，kdump 会在缺少 RAM 时自动构建 initramfs。
(BZ#1723492)
