Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Resolved an issue where deleting or enrolling Secure Boot signatures via the Redfish API could fail. The failure was caused by an internal data structure mismatch that resulted in incorrect task data processing for Redfish-based Secure Boot key operations.

Resolved an issue where POST messages were not generated when a fan was removed from the system.

Resolved an issue where the iLO firmware version could be reported as 0.0 in the SPDM module on some platforms due to a timing dependency during firmware version retrieval.

Resolved an issue where the Secure Boot "View Signatures" display could not show certain database (DB) keys that use SHA-384 or SHA-512 signature algorithms.

Resolved an issue where iLO environment variables (EVs) were not restored after an iLO factory reset, which could cause multiple iLO functions to stop working until the next system boot.

Resolved an issue where the drive count displayed on the iLO Drives page could be incomplete due to incorrect drive identification for direct-attached storage devices.

Resolved an issue where the SPDM device authentication policy could be incorrectly read from a fallback path, potentially causing SPDM device authentication to be skipped during boot.

Resolved an issue where the system serial number could be missing after an AC power cycle due to a management interface command timeout during early boot.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Resolved an issue where deleting or enrolling Secure Boot signatures via the Redfish API could fail. The failure was caused by an internal data structure mismatch that resulted in incorrect task data processing for Redfish-based Secure Boot key operations.

Resolved an issue where POST messages were not generated when a fan was removed from the system.

Resolved an issue where the iLO firmware version could be reported as 0.0 in the SPDM module on some platforms due to a timing dependency during firmware version retrieval.

Resolved an issue where the Secure Boot "View Signatures" display could not show certain database (DB) keys that use SHA-384 or SHA-512 signature algorithms.

Resolved an issue where iLO environment variables (EVs) were not restored after an iLO factory reset, which could cause multiple iLO functions to stop working until the next system boot.

Resolved an issue where the drive count displayed on the iLO Drives page could be incomplete due to incorrect drive identification for direct-attached storage devices.

Resolved an issue where the SPDM device authentication policy could be incorrectly read from a fallback path, potentially causing SPDM device authentication to be skipped during boot.

Resolved an issue where the system serial number could be missing after an AC power cycle due to a management interface command timeout during early boot.

Known Issues:

This revision of the System ROM includes AMD reference code TurinPI 1.0.0B for AMD 5th Generation EPYC processors.

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

None

Problems Fixed:

Addressed an issue where HPE Smart Memory DIMMs could be incorrectly identified as non-Smart Memory.

Addressed an issue where NVMe-oF IPv6 target hard drives were not detected during VMware 9.0 installation.

Addressed an issue where an iLO-initiated NMI Blue Screen of Death (BSOD) could not be generated on Windows Server when Hyper-V was enabled.

Addressed an intermittent Purple Screen of Death (PSOD) that could occur during VMware ESXi 9.1 installation due to an inconsistency in processor virtualization register lock status across CPU cores.

Addressed an issue where the system could hang during boot when Intelligent Provisioning support was removed from the platform configuration.

Addressed an intermittent system assert that could occur during boot due to a timing condition in platform defaults initialization.

Addressed an issue where the EFI Shell startup.nsh script execution order did not follow the configured Shell Auto-Start Script Location setting. When set to "File Systems on Attached Media," the network location script could still execute first.

Addressed an issue where the redundant power supply requirement setting could display incorrectly in RBSU when using an OEM image.

Addressed an issue where Self-Encrypting Drive (SED) lock, unlock, or secure erase operations could fail or produce unexpected results if the management controller returned invalid key data. Improved error handling now validates the response before proceeding with drive operations.

Addressed an issue where IML entries for Mission Critical Mode events displayed a static controller name instead of the dynamically branded name.

Addressed the following security vulnerabilities:

- CVE-2026-42770 (OpenSSL)

- CVE-2026-45447 (OpenSSL)

- CVE-2026-7383 (OpenSSL)

- CVE-2026-42767 (OpenSSL)

- CVE-2026-34180 (OpenSSL)

- CVE-2026-34757 (Libpng)

- CVE-2014-9485 (MiniZip)

Known Issues:

None

This revision of the System ROM includes AMD reference code TurinPI 1.0.0B for AMD 5th Generation EPYC processors.

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

None

Problems Fixed:

Addressed an issue where HPE Smart Memory DIMMs could be incorrectly identified as non-Smart Memory.

Addressed an issue where NVMe-oF IPv6 target hard drives were not detected during VMware 9.0 installation.

Addressed an issue where an iLO-initiated NMI Blue Screen of Death (BSOD) could not be generated on Windows Server when Hyper-V was enabled.

Addressed an intermittent Purple Screen of Death (PSOD) that could occur during VMware ESXi 9.1 installation due to an inconsistency in processor virtualization register lock status across CPU cores.

Addressed an issue where the system could hang during boot when Intelligent Provisioning support was removed from the platform configuration.

Addressed an intermittent system assert that could occur during boot due to a timing condition in platform defaults initialization.

Addressed an issue where the EFI Shell startup.nsh script execution order did not follow the configured Shell Auto-Start Script Location setting. When set to "File Systems on Attached Media," the network location script could still execute first.

Addressed an issue where the redundant power supply requirement setting could display incorrectly in RBSU when using an OEM image.

Addressed an issue where Self-Encrypting Drive (SED) lock, unlock, or secure erase operations could fail or produce unexpected results if the management controller returned invalid key data. Improved error handling now validates the response before proceeding with drive operations.

Addressed an issue where IML entries for Mission Critical Mode events displayed a static controller name instead of the dynamically branded name.

Addressed the following security vulnerabilities:

- CVE-2026-42770 (OpenSSL)

- CVE-2026-45447 (OpenSSL)

- CVE-2026-7383 (OpenSSL)

- CVE-2026-42767 (OpenSSL)

- CVE-2026-34180 (OpenSSL)

- CVE-2026-34757 (Libpng)

- CVE-2014-9485 (MiniZip)

Known Issues:

None

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the system might get stuck at SMBIOS table initialization when performing power cycling via IPMI command.

Addressed an issue where the system did not automatically power on after a Mission Critical Mode auxiliary power cycle.

Addressed an issue where BIOS settings might not revert to platform defaults when BMC configuration overrides are cleared.

Addressed an issue where memory could get stuck at 6000 MT/s in 2-DIMM per channel configurations after a BIOS downgrade to an earlier version.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the system might get stuck at SMBIOS table initialization when performing power cycling via IPMI command.

Addressed an issue where the system did not automatically power on after a Mission Critical Mode auxiliary power cycle.

Addressed an issue where BIOS settings might not revert to platform defaults when BMC configuration overrides are cleared.

Addressed an issue where memory could get stuck at 6000 MT/s in 2-DIMM per channel configurations after a BIOS downgrade to an earlier version.

Known Issues:

•     This firmware revision improves data integrity and reliability by optimizing adjacent track refresh parameters and management of emergency power loss table structure
•     The risk of not upgrading to this firmware is the increased possibility of data corruption in emergency power loss events
•     Several maintenance items are included in this firmware revision that reduce the probability of hangs and provide some minor performance improvements

•     This firmware revision improves data integrity and reliability by optimizing adjacent track refresh parameters and management of emergency power loss table structure
•     The risk of not upgrading to this firmware is the increased possibility of data corruption in emergency power loss events
•     Several maintenance items are included in this firmware revision that reduce the probability of hangs and provide some minor performance improvements

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the system might get stuck at SMBIOS table initialization when performing power cycling via IPMI command.

Addressed an issue where the system did not automatically power on after a Mission Critical Mode auxiliary power cycle.

Addressed an issue where BIOS settings might not revert to platform defaults when BMC configuration overrides are cleared.

Addressed an issue where memory could get stuck at 6000 MT/s in 2-DIMM per channel configurations after a BIOS downgrade to an earlier version.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the system might get stuck at SMBIOS table initialization when performing power cycling via IPMI command.

Addressed an issue where the system did not automatically power on after a Mission Critical Mode auxiliary power cycle.

Addressed an issue where BIOS settings might not revert to platform defaults when BMC configuration overrides are cleared.

Addressed an issue where memory could get stuck at 6000 MT/s in 2-DIMM per channel configurations after a BIOS downgrade to an earlier version.

Known Issues:

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• An issue on RHEL systems where installing chkconfig after mlnx-ofa_kernel (pulled in by packages such as doca-ofed and doca-host) could fail during installation. In this sequence, chkconfig could be installed indirectly as a dependency of a package that places init scripts under /etc/init.d, but the install would error out because /etc/init.d already existed as a directory (whereas chkconfig expects to manage it as a symlink). This fix prevents the /etc/init.d directory/symlink conflict that caused the RPM unpacking failure.
• In LAG mode, a firmware reset race could cause the driver to hang during unload while waiting for UMR completion. The fix ensures sys_error notifications are registered early and kept through device unregister so error events reach the bond device during teardown.
• Soft lockup warnings that could occur while releasing large UMEMs by periodically yielding the CPU during the release flow.
• A kernel crash that could occur if the devlink userspace process was terminated while switching the device to switchdev mode.
• Devlink operations were not synchronized with fw_reset, which could lead to various failures. Added a mechanism to coordinate fw_reset with devlink operations.
• The driver could incorrectly initialize polling-only CQs (e.g., ASO CQs), allowing them to receive EQ interrupts in rare cases. The CQ initialization flow was updated to prevent interrupts for polling-only CQs.
• An overflow issue where the max-rate value was stored in a unsigned 8-bit integer type , causing values above 255 to wrap (e.g., 257 became 1).
• An issue that prevented using more than 8 cores to set SF CPU affinity. This restriction has now been removed

• An issue on RHEL systems where installing chkconfig after mlnx-ofa_kernel (pulled in by packages such as doca-ofed and doca-host) could fail during installation. In this sequence, chkconfig could be installed indirectly as a dependency of a package that places init scripts under /etc/init.d, but the install would error out because /etc/init.d already existed as a directory (whereas chkconfig expects to manage it as a symlink). This fix prevents the /etc/init.d directory/symlink conflict that caused the RPM unpacking failure.
• In LAG mode, a firmware reset race could cause the driver to hang during unload while waiting for UMR completion. The fix ensures sys_error notifications are registered early and kept through device unregister so error events reach the bond device during teardown.
• Soft lockup warnings that could occur while releasing large UMEMs by periodically yielding the CPU during the release flow.
• A kernel crash that could occur if the devlink userspace process was terminated while switching the device to switchdev mode.
• Devlink operations were not synchronized with fw_reset, which could lead to various failures. Added a mechanism to coordinate fw_reset with devlink operations.
• The driver could incorrectly initialize polling-only CQs (e.g., ASO CQs), allowing them to receive EQ interrupts in rare cases. The CQ initialization flow was updated to prevent interrupts for polling-only CQs.
• An overflow issue where the max-rate value was stored in a unsigned 8-bit integer type , causing values above 255 to wrap (e.g., 257 became 1).
• An issue that prevented using more than 8 cores to set SF CPU affinity. This restriction has now been removed

• CREATE_PARSE_GRAPH_NODE incorrectly applied validation intended for WA mode, in which header_length_field_offset is adjusted by firmware. Since ConnectX-8 and newer adapters use normal mode only, these checks were redundant and could reject valid input. Validation is now mode-specific: normal-mode rules are applied on ConnectX-8 and newer adapters, while WA-mode rules are applied on older adapters.
• The firmware did not enforce the adapter limit for the number of flow match samples per parse graph node across the device. As a result, creation could succeed even when the total exceeded the hardware-supported limit. Firmware now enforces this limit before allocating samples. Creating a parse graph node that would exceed the maximum number of hardware flow match samples now fails with a “no resources” error.
• When Flex Parser overwrite native arc was enabled, destroying or closing a parse graph node on a native protocol arc did not restore the native protocol parser. As a result, the native parser remained unavailable on the device until a reset or another recovery action was performed. Native protocol parsing is now restored as expected when the parse graph node is closed or destroyed. Native parsers are disabled only while the Flex Parser graph owns the arc.
• A corner-case race condition triggered by DSP resets, causing the link to be unresponsive.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• In rare cases, certain module types experienced link-up failures.
• After toggling all ports, one port could become unresponsive in the Receiver Detect state.
• Repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• NSM did not function reliably in multihost configurations when a DMA physical function (PF) was present.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• Queue pairs (QPs) created during a PCC process transition could miss congestion-control (CC) information, preventing them from being fully managed.
• The LAG layer steering table had only one strict-SQ entry, causing strict no-port-select traffic to be routed to a single default port. With LOAD_BALANCE_MODE_P1=3, this could lead to link flapping because LACP packets were transmitted only from that default port. The fix expands the LAG layer steering table and adds additional strict-port entries to distribute strict traffic correctly.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestioncontrol algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• An issue during hitless upgrade where, after the SACK generation/handler fence, firmware could mark the old port configuration ID as invalid. If SACK causes were still active, a race could cause SACK ISRs to stop unexpectedly. The fix is to always return BUSY while handover is active.
• When using multiplane ZTRCC congestion control with multiple flows, the RTT timeout counter in the PPCC register could increase even when the network was not congested.
• A firmware race condition between packet receive and QP cleanup could move a QP to error when reopening the same QP and sending the same MSN. This could occur when interrupting traffic (e.g., Ctrl+C) and running many iterations until the same QP/MSN combination is reused.
• The FMT Static PF verifier did not account for the Tools PF when verifying the DMA PF. 
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.
• One-to-one RoCE traffic using a single QP might not achieve line rate on some platforms when using the default ROCE_CC_COMPATIBILITY_MODE setting in mlxconfig.
• In some configurations with ConnectX-8 connected to an MP3 switch, the link might fail to come up on the switch side after toggling ports. In these cases, ConnectX-8 reported opcode 14, indicating detected remote faults and that the partner was not bringing the link up.
• ACS errors could occur due to a race condition when performing LDE/SBR while MCTP traffic to the device was active.
• A potential routing error when IOVAs assigned to the NIC overlap with the PCIe address space. In certain configurations, an IOVA could fall into an “unclaimed address” range, within a PCIe switch’s Upstream Port (USP) window but outside any Downstream Port (DSP) aperture. Note: Since this is a kernel issue, to ensure packets are routed correctly in these scenarios, users must enable the ACS Unclaimed Request Redirect bit in the PCIe bridges’ Access Control Services (ACS) capability via the kernel.
• Partially enabling ACS enhanced capability could cause unexpected driver and system behavior. ACS enhanced capability remains disabled and will not be enabled.

• CREATE_PARSE_GRAPH_NODE incorrectly applied validation intended for WA mode, in which header_length_field_offset is adjusted by firmware. Since ConnectX-8 and newer adapters use normal mode only, these checks were redundant and could reject valid input. Validation is now mode-specific: normal-mode rules are applied on ConnectX-8 and newer adapters, while WA-mode rules are applied on older adapters.
• The firmware did not enforce the adapter limit for the number of flow match samples per parse graph node across the device. As a result, creation could succeed even when the total exceeded the hardware-supported limit. Firmware now enforces this limit before allocating samples. Creating a parse graph node that would exceed the maximum number of hardware flow match samples now fails with a “no resources” error.
• When Flex Parser overwrite native arc was enabled, destroying or closing a parse graph node on a native protocol arc did not restore the native protocol parser. As a result, the native parser remained unavailable on the device until a reset or another recovery action was performed. Native protocol parsing is now restored as expected when the parse graph node is closed or destroyed. Native parsers are disabled only while the Flex Parser graph owns the arc.
• A corner-case race condition triggered by DSP resets, causing the link to be unresponsive.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• In rare cases, certain module types experienced link-up failures.
• After toggling all ports, one port could become unresponsive in the Receiver Detect state.
• Repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• NSM did not function reliably in multihost configurations when a DMA physical function (PF) was present.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• Queue pairs (QPs) created during a PCC process transition could miss congestion-control (CC) information, preventing them from being fully managed.
• The LAG layer steering table had only one strict-SQ entry, causing strict no-port-select traffic to be routed to a single default port. With LOAD_BALANCE_MODE_P1=3, this could lead to link flapping because LACP packets were transmitted only from that default port. The fix expands the LAG layer steering table and adds additional strict-port entries to distribute strict traffic correctly.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestioncontrol algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• An issue during hitless upgrade where, after the SACK generation/handler fence, firmware could mark the old port configuration ID as invalid. If SACK causes were still active, a race could cause SACK ISRs to stop unexpectedly. The fix is to always return BUSY while handover is active.
• When using multiplane ZTRCC congestion control with multiple flows, the RTT timeout counter in the PPCC register could increase even when the network was not congested.
• A firmware race condition between packet receive and QP cleanup could move a QP to error when reopening the same QP and sending the same MSN. This could occur when interrupting traffic (e.g., Ctrl+C) and running many iterations until the same QP/MSN combination is reused.
• The FMT Static PF verifier did not account for the Tools PF when verifying the DMA PF. 
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.
• One-to-one RoCE traffic using a single QP might not achieve line rate on some platforms when using the default ROCE_CC_COMPATIBILITY_MODE setting in mlxconfig.
• In some configurations with ConnectX-8 connected to an MP3 switch, the link might fail to come up on the switch side after toggling ports. In these cases, ConnectX-8 reported opcode 14, indicating detected remote faults and that the partner was not bringing the link up.
• ACS errors could occur due to a race condition when performing LDE/SBR while MCTP traffic to the device was active.
• A potential routing error when IOVAs assigned to the NIC overlap with the PCIe address space. In certain configurations, an IOVA could fall into an “unclaimed address” range, within a PCIe switch’s Upstream Port (USP) window but outside any Downstream Port (DSP) aperture. Note: Since this is a kernel issue, to ensure packets are routed correctly in these scenarios, users must enable the ACS Unclaimed Request Redirect bit in the PCIe bridges’ Access Control Services (ACS) capability via the kernel.
• Partially enabling ACS enhanced capability could cause unexpected driver and system behavior. ACS enhanced capability remains disabled and will not be enabled.

• In certain configurations with the ConnectX-8 PCIe switch enabled, downstream devices (including GPUs) might not be detected and could drop from the PCI bus, with GPU sensors/properties reporting NA. This was caused by the device not receiving the required PERST# assertion during initialization, and was seen only when PCIe settings were manually modified via mlxconfig (e.g., restricting link speed/width or ASPM on specific PCI buses).
• The DPA kernel used unsafe ICM access during process creation/modification, which could cause the DPA kernel to hang during FLR.
• Link failures were occasionally observed at PAM4 speeds over optical interfaces in rare cases.
• An issue in the User Debugger “query caps” where it returned only the number of capabilities, not the capability bitmap.
• CR dumps could time out when accessing xpl_top addresses across all three pcores.
• The Virtio and NVMe EMU_MNG settings were exposed incorrectly, which could cause confusion when using mlxconfig.
• The PHY LED could show green during the initializing state when active speed was set to full speed. In IB mode, the initializing-state LED should be amber only.
• On multi-PF-per-port systems, a PF FLR could impact the traffic bandwidth of other PFs on the same port.
• PTP could converge to an incorrect time/offset and report an inaccurate path delay.
• In Flit Mode, the device could become unresponsive when receiving malformed or invalid traffic from a link partner.
• "mlxlink" reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Parallel accesses to the MCIA register could return incorrect data. In some hosts running ethtool -m <interface> repeatedly (e.g., once per second), this could intermittently report Identifier: 0x00 (unknown/no module), causing health checks to fail.
• A rare attestation certificate signature formatting issue leading to an unnecessary zero byte in the “r” or “s” value.
• In certain Gen6 setups, RDMA READ bidirectional traffic required at least 5 QPs to reach full wire speed.
• An issue affecting single-process, unidirectional RDMA READ to GPU memory (4 QPs, 128KB messages) by enabling ZERO_TOUCH_TUNING_ENABLE via MLXCONFIG.
• An issue where probe packets might not be sent under heavy traffic.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• An intX message was sent with a Requester ID of 0, causing an ACS violation at the root port. The fix uses the correct BDF as the Requester ID instead of 0.

• In certain configurations with the ConnectX-8 PCIe switch enabled, downstream devices (including GPUs) might not be detected and could drop from the PCI bus, with GPU sensors/properties reporting NA. This was caused by the device not receiving the required PERST# assertion during initialization, and was seen only when PCIe settings were manually modified via mlxconfig (e.g., restricting link speed/width or ASPM on specific PCI buses).
• The DPA kernel used unsafe ICM access during process creation/modification, which could cause the DPA kernel to hang during FLR.
• Link failures were occasionally observed at PAM4 speeds over optical interfaces in rare cases.
• An issue in the User Debugger “query caps” where it returned only the number of capabilities, not the capability bitmap.
• CR dumps could time out when accessing xpl_top addresses across all three pcores.
• The Virtio and NVMe EMU_MNG settings were exposed incorrectly, which could cause confusion when using mlxconfig.
• The PHY LED could show green during the initializing state when active speed was set to full speed. In IB mode, the initializing-state LED should be amber only.
• On multi-PF-per-port systems, a PF FLR could impact the traffic bandwidth of other PFs on the same port.
• PTP could converge to an incorrect time/offset and report an inaccurate path delay.
• In Flit Mode, the device could become unresponsive when receiving malformed or invalid traffic from a link partner.
• "mlxlink" reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Parallel accesses to the MCIA register could return incorrect data. In some hosts running ethtool -m <interface> repeatedly (e.g., once per second), this could intermittently report Identifier: 0x00 (unknown/no module), causing health checks to fail.
• A rare attestation certificate signature formatting issue leading to an unnecessary zero byte in the “r” or “s” value.
• In certain Gen6 setups, RDMA READ bidirectional traffic required at least 5 QPs to reach full wire speed.
• An issue affecting single-process, unidirectional RDMA READ to GPU memory (4 QPs, 128KB messages) by enabling ZERO_TOUCH_TUNING_ENABLE via MLXCONFIG.
• An issue where probe packets might not be sent under heavy traffic.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• An intX message was sent with a Requester ID of 0, causing an ACS violation at the root port. The fix uses the correct BDF as the Requester ID instead of 0.

• Garbled characters are observed in the System Utilities(F9) configuration screens with Japanese Environment when HPE Emulex Fibre Channel Host Bus Adapter is installed on ProLiant Gen11 and ProLiant Gen12 servers
• Unified Extensible Firmware Interface (UEFI) protocol driver does not complete the polling device; causing the UEFI diagnostics system board component test incomplete.

• Garbled characters are observed in the System Utilities(F9) configuration screens with Japanese Environment when HPE Emulex Fibre Channel Host Bus Adapter is installed on ProLiant Gen11 and ProLiant Gen12 servers
• Unified Extensible Firmware Interface (UEFI) protocol driver does not complete the polling device; causing the UEFI diagnostics system board component test incomplete.

SPDM - Get Certificate response returns out of bound values

SPDM - Get Certificate response returns out of bound values

• NSM Get-Port-Network-Addresses returned an invalid format on B200/B300 HMC. It now follows the documented non-compact format.
• An issue that could prevent the adapter’s PCIe link from re-establishing after the host resumed from a deep power-down state. This fix improves the reliability of suspend/resume cycles.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• An issue where repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• vDPA doorbell resources were not released, which could cause failures when running other functionality after a vDPA FLR. Doorbell resources are now properly unlocked.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestion-control algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• A precopy image was processed during the stop-copy phase, causing prolonged downtime due to a software limitation. The handling was slow because the handler performed a linear search for data; this was improved by replacing it with a faster search approach enabled via compile-time preprocessing.
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.

• NSM Get-Port-Network-Addresses returned an invalid format on B200/B300 HMC. It now follows the documented non-compact format.
• An issue that could prevent the adapter’s PCIe link from re-establishing after the host resumed from a deep power-down state. This fix improves the reliability of suspend/resume cycles.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• An issue where repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• vDPA doorbell resources were not released, which could cause failures when running other functionality after a vDPA FLR. Doorbell resources are now properly unlocked.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestion-control algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• A precopy image was processed during the stop-copy phase, causing prolonged downtime due to a software limitation. The handling was slow because the handler performed a linear search for data; this was improved by replacing it with a faster search approach enabled via compile-time preprocessing.
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.

• An interoperability issue where, when ConnectX-7 communicates with ConnectX-8 using the probe-based algorithm, bandwidth could become extremely low due to probe packets being dropped.
• The DPA kernel used unsafe ICM access during process creation/modification, which would cause the DPA kernel to hang during FLR.
• User Debugger “query caps” returned only the number of capabilities, not the capability bitmap.
• Race condition in standby/boot power sequencing. In certain timing windows, port power-down would be delayed such that the power-up flow detected the port still transitioning to power-down, causing the sequence to fail and leaving the port stuck in a powered-down state.
• mlxlink reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Due to an SMBus release race condition, the I2C bus would become stuck.
• Fuse values were not aligned with the updated values burned across different ConnectX-7 setups.
• Issue in the steering definers used for LAG with IPv6 traffic.
• A spurious CNP was sent in response to an out-of-sequence packet.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• When decapsulation on a packet occurred, the FCS indication was not calculated correctly.
• In IB system, RTT_response_sl feature did not work with Sniffer tools (e.g., Wireshark/Tcpdump/).
   

• An interoperability issue where, when ConnectX-7 communicates with ConnectX-8 using the probe-based algorithm, bandwidth could become extremely low due to probe packets being dropped.
• The DPA kernel used unsafe ICM access during process creation/modification, which would cause the DPA kernel to hang during FLR.
• User Debugger “query caps” returned only the number of capabilities, not the capability bitmap.
• Race condition in standby/boot power sequencing. In certain timing windows, port power-down would be delayed such that the power-up flow detected the port still transitioning to power-down, causing the sequence to fail and leaving the port stuck in a powered-down state.
• mlxlink reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Due to an SMBus release race condition, the I2C bus would become stuck.
• Fuse values were not aligned with the updated values burned across different ConnectX-7 setups.
• Issue in the steering definers used for LAG with IPv6 traffic.
• A spurious CNP was sent in response to an out-of-sequence packet.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• When decapsulation on a packet occurred, the FCS indication was not calculated correctly.
• In IB system, RTT_response_sl feature did not work with Sniffer tools (e.g., Wireshark/Tcpdump/).
   

• CREATE_PARSE_GRAPH_NODE incorrectly applied validation intended for WA mode, in which header_length_field_offset is adjusted by firmware. Since ConnectX-8 and newer adapters use normal mode only, these checks were redundant and could reject valid input. Validation is now mode-specific: normal-mode rules are applied on ConnectX-8 and newer adapters, while WA-mode rules are applied on older adapters.
• The firmware did not enforce the adapter limit for the number of flow match samples per parse graph node across the device. As a result, creation could succeed even when the total exceeded the hardware-supported limit. Firmware now enforces this limit before allocating samples. Creating a parse graph node that would exceed the maximum number of hardware flow match samples now fails with a “no resources” error.
• When Flex Parser overwrite native arc was enabled, destroying or closing a parse graph node on a native protocol arc did not restore the native protocol parser. As a result, the native parser remained unavailable on the device until a reset or another recovery action was performed. Native protocol parsing is now restored as expected when the parse graph node is closed or destroyed. Native parsers are disabled only while the Flex Parser graph owns the arc.
• A corner-case race condition triggered by DSP resets, causing the link to be unresponsive.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• In rare cases, certain module types experienced link-up failures.
• After toggling all ports, one port could become unresponsive in the Receiver Detect state.
• Repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• NSM did not function reliably in multihost configurations when a DMA physical function (PF) was present.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• Queue pairs (QPs) created during a PCC process transition could miss congestion-control (CC) information, preventing them from being fully managed.
• The LAG layer steering table had only one strict-SQ entry, causing strict no-port-select traffic to be routed to a single default port. With LOAD_BALANCE_MODE_P1=3, this could lead to link flapping because LACP packets were transmitted only from that default port. The fix expands the LAG layer steering table and adds additional strict-port entries to distribute strict traffic correctly.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestioncontrol algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• An issue during hitless upgrade where, after the SACK generation/handler fence, firmware could mark the old port configuration ID as invalid. If SACK causes were still active, a race could cause SACK ISRs to stop unexpectedly. The fix is to always return BUSY while handover is active.
• When using multiplane ZTRCC congestion control with multiple flows, the RTT timeout counter in the PPCC register could increase even when the network was not congested.
• A firmware race condition between packet receive and QP cleanup could move a QP to error when reopening the same QP and sending the same MSN. This could occur when interrupting traffic (e.g., Ctrl+C) and running many iterations until the same QP/MSN combination is reused.
• The FMT Static PF verifier did not account for the Tools PF when verifying the DMA PF. 
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.
• One-to-one RoCE traffic using a single QP might not achieve line rate on some platforms when using the default ROCE_CC_COMPATIBILITY_MODE setting in mlxconfig.
• In some configurations with ConnectX-8 connected to an MP3 switch, the link might fail to come up on the switch side after toggling ports. In these cases, ConnectX-8 reported opcode 14, indicating detected remote faults and that the partner was not bringing the link up.
• ACS errors could occur due to a race condition when performing LDE/SBR while MCTP traffic to the device was active.
• A potential routing error when IOVAs assigned to the NIC overlap with the PCIe address space. In certain configurations, an IOVA could fall into an “unclaimed address” range, within a PCIe switch’s Upstream Port (USP) window but outside any Downstream Port (DSP) aperture. Note: Since this is a kernel issue, to ensure packets are routed correctly in these scenarios, users must enable the ACS Unclaimed Request Redirect bit in the PCIe bridges’ Access Control Services (ACS) capability via the kernel.
• Partially enabling ACS enhanced capability could cause unexpected driver and system behavior. ACS enhanced capability remains disabled and will not be enabled.

• CREATE_PARSE_GRAPH_NODE incorrectly applied validation intended for WA mode, in which header_length_field_offset is adjusted by firmware. Since ConnectX-8 and newer adapters use normal mode only, these checks were redundant and could reject valid input. Validation is now mode-specific: normal-mode rules are applied on ConnectX-8 and newer adapters, while WA-mode rules are applied on older adapters.
• The firmware did not enforce the adapter limit for the number of flow match samples per parse graph node across the device. As a result, creation could succeed even when the total exceeded the hardware-supported limit. Firmware now enforces this limit before allocating samples. Creating a parse graph node that would exceed the maximum number of hardware flow match samples now fails with a “no resources” error.
• When Flex Parser overwrite native arc was enabled, destroying or closing a parse graph node on a native protocol arc did not restore the native protocol parser. As a result, the native parser remained unavailable on the device until a reset or another recovery action was performed. Native protocol parsing is now restored as expected when the parse graph node is closed or destroyed. Native parsers are disabled only while the Flex Parser graph owns the arc.
• A corner-case race condition triggered by DSP resets, causing the link to be unresponsive.
• A DEAD IRISC assert that could occur during TLV NV_DATA flash access by suspending the watchdog while waiting for flash IPC (until timeout), preventing the assert on TLV access.
• In rare cases, certain module types experienced link-up failures.
• After toggling all ports, one port could become unresponsive in the Receiver Detect state.
• Repeatedly writing NVCONFIG TLVs could cause excessive NV_DATA partition swaps during garbage collection. This rapid cycling could accelerate flash wear (end-of-life at 100,000 erases) and potentially render the device inoperable. Firmware now avoids unnecessary physical writes by returning OK when the requested configuration already exists in flash, and increases the maximum supported NV_DATA partition swaps from 100,000 to 200,000.
• NSM did not function reliably in multihost configurations when a DMA physical function (PF) was present.
• ICM_RES_HW_DMFS_ENCAP_H_FW was allocated per GVMI, preventing some RTTs from using it.
• Queue pairs (QPs) created during a PCC process transition could miss congestion-control (CC) information, preventing them from being fully managed.
• The LAG layer steering table had only one strict-SQ entry, causing strict no-port-select traffic to be routed to a single default port. With LOAD_BALANCE_MODE_P1=3, this could lead to link flapping because LACP packets were transmitted only from that default port. The fix expands the LAG layer steering table and adds additional strict-port entries to distribute strict traffic correctly.
• RDMA traffic could stall in large-scale deployments for certain source IP and UDP source-port combinations when DOCA PCC was active and no congestioncontrol algorithm was configured in algorithm slot 0.
• The live migration target did not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• An issue during hitless upgrade where, after the SACK generation/handler fence, firmware could mark the old port configuration ID as invalid. If SACK causes were still active, a race could cause SACK ISRs to stop unexpectedly. The fix is to always return BUSY while handover is active.
• When using multiplane ZTRCC congestion control with multiple flows, the RTT timeout counter in the PPCC register could increase even when the network was not congested.
• A firmware race condition between packet receive and QP cleanup could move a QP to error when reopening the same QP and sending the same MSN. This could occur when interrupting traffic (e.g., Ctrl+C) and running many iterations until the same QP/MSN combination is reused.
• The FMT Static PF verifier did not account for the Tools PF when verifying the DMA PF. 
• QPs established before loading DOCA PCC could exhibit inconsistent algorithm-selected behavior between ports in LAG mode after DOCA PCC is loaded.
• One-to-one RoCE traffic using a single QP might not achieve line rate on some platforms when using the default ROCE_CC_COMPATIBILITY_MODE setting in mlxconfig.
• In some configurations with ConnectX-8 connected to an MP3 switch, the link might fail to come up on the switch side after toggling ports. In these cases, ConnectX-8 reported opcode 14, indicating detected remote faults and that the partner was not bringing the link up.
• ACS errors could occur due to a race condition when performing LDE/SBR while MCTP traffic to the device was active.
• A potential routing error when IOVAs assigned to the NIC overlap with the PCIe address space. In certain configurations, an IOVA could fall into an “unclaimed address” range, within a PCIe switch’s Upstream Port (USP) window but outside any Downstream Port (DSP) aperture. Note: Since this is a kernel issue, to ensure packets are routed correctly in these scenarios, users must enable the ACS Unclaimed Request Redirect bit in the PCIe bridges’ Access Control Services (ACS) capability via the kernel.
• Partially enabling ACS enhanced capability could cause unexpected driver and system behavior. ACS enhanced capability remains disabled and will not be enabled.

• In certain configurations with the ConnectX-8 PCIe switch enabled, downstream devices (including GPUs) might not be detected and could drop from the PCI bus, with GPU sensors/properties reporting NA. This was caused by the device not receiving the required PERST# assertion during initialization, and was seen only when PCIe settings were manually modified via mlxconfig (e.g., restricting link speed/width or ASPM on specific PCI buses).
• The DPA kernel used unsafe ICM access during process creation/modification, which could cause the DPA kernel to hang during FLR.
• Link failures were occasionally observed at PAM4 speeds over optical interfaces in rare cases.
• An issue in the User Debugger “query caps” where it returned only the number of capabilities, not the capability bitmap.
• CR dumps could time out when accessing xpl_top addresses across all three pcores.
• The Virtio and NVMe EMU_MNG settings were exposed incorrectly, which could cause confusion when using mlxconfig.
• The PHY LED could show green during the initializing state when active speed was set to full speed. In IB mode, the initializing-state LED should be amber only.
• On multi-PF-per-port systems, a PF FLR could impact the traffic bandwidth of other PFs on the same port.
• PTP could converge to an incorrect time/offset and report an inaccurate path delay.
• In Flit Mode, the device could become unresponsive when receiving malformed or invalid traffic from a link partner.
• "mlxlink" reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Parallel accesses to the MCIA register could return incorrect data. In some hosts running ethtool -m <interface> repeatedly (e.g., once per second), this could intermittently report Identifier: 0x00 (unknown/no module), causing health checks to fail.
• A rare attestation certificate signature formatting issue leading to an unnecessary zero byte in the “r” or “s” value.
• In certain Gen6 setups, RDMA READ bidirectional traffic required at least 5 QPs to reach full wire speed.
• An issue affecting single-process, unidirectional RDMA READ to GPU memory (4 QPs, 128KB messages) by enabling ZERO_TOUCH_TUNING_ENABLE via MLXCONFIG.
• An issue where probe packets might not be sent under heavy traffic.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• An intX message was sent with a Requester ID of 0, causing an ACS violation at the root port. The fix uses the correct BDF as the Requester ID instead of 0.

• In certain configurations with the ConnectX-8 PCIe switch enabled, downstream devices (including GPUs) might not be detected and could drop from the PCI bus, with GPU sensors/properties reporting NA. This was caused by the device not receiving the required PERST# assertion during initialization, and was seen only when PCIe settings were manually modified via mlxconfig (e.g., restricting link speed/width or ASPM on specific PCI buses).
• The DPA kernel used unsafe ICM access during process creation/modification, which could cause the DPA kernel to hang during FLR.
• Link failures were occasionally observed at PAM4 speeds over optical interfaces in rare cases.
• An issue in the User Debugger “query caps” where it returned only the number of capabilities, not the capability bitmap.
• CR dumps could time out when accessing xpl_top addresses across all three pcores.
• The Virtio and NVMe EMU_MNG settings were exposed incorrectly, which could cause confusion when using mlxconfig.
• The PHY LED could show green during the initializing state when active speed was set to full speed. In IB mode, the initializing-state LED should be amber only.
• On multi-PF-per-port systems, a PF FLR could impact the traffic bandwidth of other PFs on the same port.
• PTP could converge to an incorrect time/offset and report an inaccurate path delay.
• In Flit Mode, the device could become unresponsive when receiving malformed or invalid traffic from a link partner.
• "mlxlink" reported 0 values for SNR (media and host) due to incorrect local port mapping in firmware and an incorrect page number used by MFT.
• Parallel accesses to the MCIA register could return incorrect data. In some hosts running ethtool -m <interface> repeatedly (e.g., once per second), this could intermittently report Identifier: 0x00 (unknown/no module), causing health checks to fail.
• A rare attestation certificate signature formatting issue leading to an unnecessary zero byte in the “r” or “s” value.
• In certain Gen6 setups, RDMA READ bidirectional traffic required at least 5 QPs to reach full wire speed.
• An issue affecting single-process, unidirectional RDMA READ to GPU memory (4 QPs, 128KB messages) by enabling ZERO_TOUCH_TUNING_ENABLE via MLXCONFIG.
• An issue where probe packets might not be sent under heavy traffic.
• The root complex sent MCTP-over-PCI messages before a BDF was assigned, causing responses to be sent with BDF 0. The fix ensures that MCTP messages routed by ID are ignored until a valid BDF is assigned.
• The steering tables were not updated after enabling partial Spectrum-X capabilities (BTH.AR) via LLPD.
• An intX message was sent with a Requester ID of 0, causing an ACS violation at the root port. The fix uses the correct BDF as the Requester ID instead of 0.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• A BlueField-3 host SF could remain stuck in the inactive+attached state and fail to reactivate after host restart flows.
• A NULL pointer dereference in the mlx5_core driver that could cause a kernel panic and report PCIe completion-timeout errors on ConnectX-8 bare-metal systems.
• An issue that occurred when CONFIG_UBSAN=y and the user provided an invalid value, resulting in the following UBSAN error:UBSAN: shift-out-of-bounds in drivers/net/ethernet/mellanox/mlx5/core/diag/diag_cnt.c:190:11 shift exponent 4294967293 is too large for 32-bit type 'int'
• A race condition in the ib_core kernel module during concurrent address resolution that could produce a zero destination MAC (DMAC), causing silent packet loss and RDMA retry-exceeded errors.
• Upgrading doca-ofed did not always upgrade doca-extra (which includes the module sources and doca-kernel-support build scripts). In some cases, this caused doca-kernel-support to build against sources from an older release.
• Accessing timestamping mode could fail on kernel 7.0 and later.

• An issue on RHEL systems where installing chkconfig after mlnx-ofa_kernel (pulled in by packages such as doca-ofed and doca-host) could fail during installation. In this sequence, chkconfig could be installed indirectly as a dependency of a package that places init scripts under /etc/init.d, but the install would error out because /etc/init.d already existed as a directory (whereas chkconfig expects to manage it as a symlink). This fix prevents the /etc/init.d directory/symlink conflict that caused the RPM unpacking failure.
• In LAG mode, a firmware reset race could cause the driver to hang during unload while waiting for UMR completion. The fix ensures sys_error notifications are registered early and kept through device unregister so error events reach the bond device during teardown.
• Soft lockup warnings that could occur while releasing large UMEMs by periodically yielding the CPU during the release flow.
• A kernel crash that could occur if the devlink userspace process was terminated while switching the device to switchdev mode.
• Devlink operations were not synchronized with fw_reset, which could lead to various failures. Added a mechanism to coordinate fw_reset with devlink operations.
• The driver could incorrectly initialize polling-only CQs (e.g., ASO CQs), allowing them to receive EQ interrupts in rare cases. The CQ initialization flow was updated to prevent interrupts for polling-only CQs.
• An overflow issue where the max-rate value was stored in a unsigned 8-bit integer type , causing values above 255 to wrap (e.g., 257 became 1).
• An issue that prevented using more than 8 cores to set SF CPU affinity. This restriction has now been removed.

• An issue on RHEL systems where installing chkconfig after mlnx-ofa_kernel (pulled in by packages such as doca-ofed and doca-host) could fail during installation. In this sequence, chkconfig could be installed indirectly as a dependency of a package that places init scripts under /etc/init.d, but the install would error out because /etc/init.d already existed as a directory (whereas chkconfig expects to manage it as a symlink). This fix prevents the /etc/init.d directory/symlink conflict that caused the RPM unpacking failure.
• In LAG mode, a firmware reset race could cause the driver to hang during unload while waiting for UMR completion. The fix ensures sys_error notifications are registered early and kept through device unregister so error events reach the bond device during teardown.
• Soft lockup warnings that could occur while releasing large UMEMs by periodically yielding the CPU during the release flow.
• A kernel crash that could occur if the devlink userspace process was terminated while switching the device to switchdev mode.
• Devlink operations were not synchronized with fw_reset, which could lead to various failures. Added a mechanism to coordinate fw_reset with devlink operations.
• The driver could incorrectly initialize polling-only CQs (e.g., ASO CQs), allowing them to receive EQ interrupts in rare cases. The CQ initialization flow was updated to prevent interrupts for polling-only CQs.
• An overflow issue where the max-rate value was stored in a unsigned 8-bit integer type , causing values above 255 to wrap (e.g., 257 became 1).
• An issue that prevented using more than 8 cores to set SF CPU affinity. This restriction has now been removed.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

• Live migration target would not receive a port state change event on the resume VHCA command. The target now generates this event so software that depends on port state is notified of any changes.
• PCC issue where RDMA traffic would stall at large scale for certain IP and UDP source-port combinations when a PCC user algorithm was active and no CC algorithm was configured in slot 0.

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues:

Details about reported security vulnerabilities and their mitigation can be found at the following link Security Bulletin Library | HPE Support.

To streamline content and avoid duplication across documents, starting the Gen12 platform, the UEFI Workload Based Profiles and Tuning Guide has been deprecated, and the contents of this document are now available as part of the current UEFI System Utilities User Guide for HPE Compute Gen12 servers based on iLO7 (https://hpe.com/support/UEFIG12-iLO7-UG-en).

Firmware Dependencies:

Problems Fixed:

Addressed an issue where the UEFI memory map could become highly fragmented, causing some operating system installers to intermittently fail to launch on BirchStream platforms.

Addressed an issue where the Custom workload profile might not retain the Collaborative Power Control (CPC) setting after an NVRAM clear, causing CPC to revert from Disabled to Enabled.

Addressed an issue where the Direct To UPI (D2K) option could not be effectively disabled in the production BIOS build.

Addressed an issue where the SPDM iLO firmware version might be reported as 0.0 on some platforms due to a cache initialization timing issue.

Addressed an issue where the SPDM Overall Boot Policy might not be read from the correct location, resulting in unexpected SPDM boot policy behavior.

Addressed an issue where BIOS settings might be lost after an iLO factory reset in CNSA mode, causing multiple iLO management functions to stop working.

Addressed an issue where the serial number might be missing after an AC power cycle.

Known Issues: