Ref # |
Issue |
3654930 |
Description: If the DPU BMC firmware has been upgraded from older versions (i.e., 2.8.2-x) to newer versions (i.e., 23.03 onward), it is necessary to execute a factory reset of the DPU BMC. |
Workaround: N/A |
|
Discovered in version: 23.03 |
|
3634649 |
Description: In the Redfish Systems/Bluefield schema, the LastResetTime does not accurately capture the system reset values. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3634701 |
Description: In the Redfish Systems/Bluefield schema, the Description attribute is of a generic type and does not specify the DPU system. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3609525 |
Description: Following a reboot of the DPU's BMC, it is necessary to wait 30 seconds to allow for the complete loading of system services before initiating a reboot of the DPU itself. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3600004 |
Description: In dual-port DPU, the DPU's Redfish schema, specifically the "chassis NetworkAdapters", will replicate the data from port 1 into port 2. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3590634 |
Description: When updating the BMC's firmware, it is critical to maintain the system powered on until the update process is finished. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3599824 |
Description: In NIC mode, the BMC's Redfish chassis schema contains only limited information about the DPU. This is because, in this mode, the OS is not available to supply the necessary information to the BMC. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3604148 |
Description: In the uncommon scenario where, following a system power cycle, the DPU fails to boot successfully, the BMC would be unable to retrieve network data from the DPU's operating system. This leads to an absence of information in the Redfish chassis schema, which is responsible for describing the network adapters. |
Workaround: Issue reset to the DPU BMC. |
|
Discovered in version: 23.09 |
|
3478796 |
Description: Rarely, it is possible for the BMC to exceed the boot timeout set by the root of trust. In such case, the RoT initiates a second reboot of the BMC, which is expected to result in a successful boot. |
Workaround: N/A |
|
Discovered in version: 23.09 |
|
3605254 |
Description: Following a system power cycle, both the DPU and BMC boot independently which may lead to the DPU's UEFI boot process to complete before the BMC's. As a result, when attempting to establish Redfish communication, the BMC may not yet be prepared to respond. |
Workaround: Power cycle; Redfish; boot |
|
Discovered in version: 23.09 |
|
3587968 |
Description: VLAN 4040 serves as a dedicated VLAN for facilitating Redfish communication between UEFI and DPU BMC. However, if the OOB RJ45 port is connected to an unmanaged switch or hub, the VLAN traffic from VLAN 4040 may spill over into the broader LAN network which may lead the local UEFI to unintentionally communicate with a remote BMC instead of the intended local BMC. |
Workaround: Ensure that the RJ45 OOB port is connected to a switch port capable of isolating this internal communication traffic from the broader LAN network. |
|
Discovered in version: 23.07-3 |
|
3566036 |
Description: After performing BF BMC factory reset, the /home/root/.ssh directory is deleted which causes the first attempt to confirm the host identity and initiate a BFB update procedure to fail while displaying the error message:
|
Workaround: Reattempt confirming the host identity and initiating the BFB update procedure. |
|
Discovered in version: 23.07-3 |
|
3561677 |
Description: It is not possible to modify the values of the BootOrder, BootOverride, and Secure Boot attributes from the UEFI menu because they are set by default to be configured from Redfish interface. |
Workaround: To directly modify these attributes from the UEFI menu, the user must disable the Redfish option in the UEFI menu. |
|
Discovered in version: 23.07-3 |
|
3388059 |
Description: When BlueField-2 boots and its services are loaded, there is a possibility that the IPMI over RMCP may become unresponsive due to the default timeout for commands being set to 1 second. |
Workaround: Increase the default timeout to 10 seconds when sending IPMI RMCP commands using the -N option. Example command:
|
|
Discovered in version: N/A |