17G systems stuck on POST with an error about HPM_SL1 cable
Hi,
I am seeing multiple R6715 systems hit this issue during routine maintenance reboots. The only way to recover is though a flea drain, which makes it extremely inconvenient for systems located in remote datacenters. The systems have various BIOS versions (incl 1.5.3 and latest 1.7.7) and iDRAC versions, including the latest
The systems in question are from different batches and were even purchased on various continents, so I'd expect other customers to see similar issues.
Exact Syslog message:
lclmanager 5430 - - Critical, Category: System Health, MessageID: HWC8010, Message: The System Configuration Check operation resulted in the following issue: cable connecting HPM_SL1 and CTRL_DP1 must be installed
Messages on the screen:
iDRAC Settings:
HWC8010: The System Configuration Check operation resulted in the following issue: cable connecting HPM_SL1 and CTRL_DP1 must be installed.
HWC8010: The System Configuration Check operation resulted in the following issue: cable connecting HPM_SL2 and CTRL_DP1 must be installed.
UEFI0459: The UEFI driver of the iDRAC Settings in an undefined location is indicating the status as Failed.
Restart the system. When the system is restarting, press the function (F11) key to view the Boot Manager. On the Boot Manager page, select the Driver Health Menu option.
Available Actions:
F1 to Continue and Retry Boot Order
F2 for System Setup (BIOS) F10 for Lifecycle Controller
- Help Install an Operating System
F11 for Boot Manager
Is this issue known and being worked on on the Dell side?
Once the server successfully cycles past POST, you must tell the iDRAC to accept the current cable topology so it stops raising false validation flags during routine reboots:
Boot the server and press F2 to enter System Setup.
Navigate to iDRAC Settings > Hardware Configuration Validation.
Change the setting to Yes (to validate/accept the current configuration).
Click Exit, select Yes to save changes, and click OK
@Dell-Martin S Thank you for your response. This is happening without the hardware config changing at all though, so I don't think it's normal. If the system gets rebooted, it will not be able to come back to the same screen, so you only get one chance of accepting the hw changes before it gets to the bad state which requires a flea drain for recovery.
I do think this bug was introduced in a recent iDRAC firmware. Quoting from this iDRAC9 KB article -
The error frequently results from a firmware update alone, with no hardware changes made to the system.
This is happening to me on iDRAC 10, but it seems like the exact same issue above. Is there a fix planned for it, for both iDRAC9 and iDRAC10?
About the other potential avenue - Is there any downside from disabling the hw config validation on all systems? What does this feature actually bring? I deal with a large fleet of thousands of such systems so the current proposed resolution is not doable, especially if the issue is likely to come back later on after another round of firmware updates.
I am giving this setting a shot, very likely it will work out fine. I'm assuming the fix will land in a future iDRAC fw release, is there currently a planned ETA for this?
Quick update on this. I have asked for a fix ETA from our tech contacts but no answer just yet, the issue does not seem well known although it seems pretty severe.
Wondering which systems should have the iDRAC.HardwareConfigValidation.ValidationState key? Does not seem valid to me, I tried on R6615 and R6715.
On the R6715/iDRAC10 I found this knob - iDRAC.PlatformCapability.HwConfigurationValidation. But could not find anything for the older generation.
Yes, you need a cold reset (or a final flea drain) for the change to take effect.
The configuration change is currently staged but inactive because the server's hardware chips are still trapped in the cached, failed state from the warm reboot.
How to apply it completely remotely:
Execute these two commands in order via RACADM to force the server to reload the setting without physical intervention:
bash
# 1. Reset the management controller to apply the new registry rule
racadm racreset soft
# 2. Trigger a remote power drain to clear the trapped error code
racadm powercycle fleadrain
Once the virtual flea drain finishes, the server will power back up and permanently ignore the HWC8010 cable validation check.
with kind regards Martin/ Liebe Grüße Martin
Did I answer your query? Please click on ‘Mark as Accepted Answer’. ‘Thumbs up’ the posts you like!
`racadm powercycle fleadrain` - is this supposed to be a racadm command? I'm not sure if it's just the forum messing with the formatting, but I could not find this documented. Or are you suggesting to set `racadm set BIOS.MiscSettings.PowerCycleRequest FullPowerCycle` and then perform a virtual flea drain remotely (this is certainly not the default setting).
Dell-Martin S
Moderator
•
3883 Posts
•
25810 Points
6
0
Posted October 5th, 2026 22:00
Hi,
* Is a fix coming? Yes.
* What does the check do? It only verifies factory cabling topologies to prevent miswiring during physical servicing.
* Any downside to disabling it? Virtually none. It does not affect hardware health, thermals, or component fault monitoring.
* Fleet fix: Disable it everywhere via RACADM:
racadm set iDRAC.HardwareConfigValidation.ValidationState Disabled
https://www.dell.com/support/kbdoc/en-us/000228171/poweredge-uefi-error-in-post-hwc8010-hwc8011?hl=de-DE#:~:text=For%20example%2C%20an%20interrupted%20firmware%20update%20or,no%20hardware%20changes%20made%20to%20the%20system
with kind regards Martin/ Liebe Grüße Martin
Did I answer your query? Please click on ‘Mark as Accepted Answer’. ‘Thumbs up’ the posts you like!
DELL-Martin S
Social Media and Communities Professional
Dell Technologies | Enterprise Support Services
#IWork4Dell