A box switch that stays dark splits into two completely different investigations the moment you pull and reseat the input power cord: it comes back, or it doesn't. What follows is how to read that first test, the log keywords for the two scenarios that show up again and again on PoE models, how to pull the power black-box log, and the full alarm field table for every power module fault code.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
One unplug-and-replug of the input power cord tells you which of two entirely different investigations you're actually running.
A box switch that won't power up is one of the more nerve-wracking calls to get, but the first diagnostic move is always the same: pull the input power cord and reseat it. If the switch comes back, the fault sits in one of three places — a cord that wasn't fully seated, a PoE chip tripped into hiccup protection by external leakage current, or a board that cut its own output after foreign debris got inside. If the switch stays dark, the fault has moved to the supply itself, the module, or the chassis. If it's the powered device on the other end of the cable that's actually the one refusing to come up, not the switch, that's a different diagnosis — see our companion note on PD-side PoE power failures.
What follows is the fault tree this splits into, the two PoE-specific scenarios worth knowing cold — leakage-triggered hiccup protection and debris-triggered short circuit — how to pull and read the power black-box log behind them, the full field table for every power module alarm keyword, and a handful of FAQ answers from real field cases.
Every one of these causes lands in one of two branches, and the reseat test is what tells you which branch you're actually in.
Placing the symptom on this tree first keeps you from swapping the power module on a fault that was never a module problem, or chasing an external-supply theory on a fault that's actually the PoE chip's own protection circuit.
Diagram labels are kept in English for engineering clarity.
The left branch is where PoE-model switches lose the most time, because the two real causes on it — leakage-triggered hiccup protection and a debris-triggered internal short — look identical from the outside and both clear (at least temporarily) with a reseat, which is exactly what makes them easy to misdiagnose as the trivial loose-cord case.
Both scenarios below sit on the branch where the switch comes back after a reseat — which is exactly why they get mistaken for the trivial case.
If the switch is a PoE model, external leakage current entering through a port can trip the PoE chip's own protection latch — and the fault log spells this out directly.
A different keyword in the same log points to something physically inside the chassis rather than current arriving over a cable.
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display power black-box log slot 0
Info: This operation may take a few seconds. Please wait a moment.......
Log information about the black box of PWR1 in slot 0:
64-FB-E9-65-01-11-00-00-64-FB-E9-65-01-01-00-00-F4-FA-E9-65-01-01-00-00-AC-FA-
E9-65-01-10-00-00-AC-FA-E9-65-01-00-00-00-BD-F7-E9-65-01-11-00-00-BC-F7-E9-65-01-01-00-00-
A3-F6-E9-65-01-10-00-00-A3-F6-E9-65-01-00-00-00-ED-F4-E9-65-01-10-00-00
// each record in the black box is a timestamped protection-state change on the power module —
// keep the raw output intact and hand it to support rather than trying to decode it by handIf reseating the cord changes nothing at all, the fault has moved off the PoE chip entirely and onto the supply, the module, or the chassis.
If the switch does come up but then fails partway through startup rather than staying dark, that's no longer a power problem at all — see our companion note on
Once display alarm shows something, the exact keyword tells you which of nine documented conditions you're looking at.
Run display alarm { all | slot slot-id } to pull the alarm, then match the keyword field against the table below alongside the module's indicator-LED state.
| Alarm keyword | Likely cause | Recommended action |
|---|---|---|
| DC PWR_FAULT | No input reaching the module (INPUT LED off, ALM red steady). | Measure the module's input voltage with a multimeter; if normal, confirm the module's switch is set to ON; if the fault persists, reseat the module, then try it in another power slot before escalating. |
| DC PWR_LACK | Input undervoltage on the module (INPUT LED off, ALM red steady). | Measure the external supply voltage and confirm it is within the rated range. |
| DC SWITCH_STA | The module's own power switch is off (INPUT LED off, ALM red steady). | Check the switch position on the module and set it to ON. |
| DC FUSE_FAULT | The protection circuit's fuse has blown (ALM red steady). | Reseat the monitor board in its slot, then try another slot; if the fault persists, reseat the power module in another power slot before escalating with the collected information. |
| PWR PWR_FAULT | General power alarm on the module (RUN off, ALM yellow steady or blinking, FAULT red steady). | Check external supply, wiring and the panel switch; if input is confirmed normal, replace the module; otherwise collect information and escalate. |
| PWR MODE FAULT | Module's own fan has failed, or its output is over- or under-voltage (RUN off, ALM yellow, FAULT red steady). | Replace the power module. |
| PWR PROTECT | The input breaker isn't closed, or the module tripped its own over-temperature, over-current, over-voltage or under-voltage protection (RUN off, ALM yellow). | Check the breaker position first, then clear whatever overload or thermal condition triggered the protection. |
| PWR DROP | The module lost its output entirely (RUN off, ALM yellow blinking). | Check whether the external input cable has worked loose; reseat it, or replace the cable if it's damaged. |
| PWR FAN FAULT | The fan inside the power module itself has failed (RUN off, ALM yellow blinking, FAULT red steady). | Replace the power module. |
Once the fault tree has told you which branch you're on, these are the ones that trip people up in the field.
SYMPTOMPoE switch won't power on; log shows PoE chip fault; reseating the input cord brings it back, at least until something is plugged into the same port again.
CAUSEThe PoE chip's own hiccup protection latched shut because leakage current came in through a port — this is the chip protecting itself, not a random hardware failure, and it will keep re-triggering for as long as the leakage source stays connected.
FIXDisconnect the suspect port, confirm the switch stays up, then chase the leakage source itself — a damp connector, poor grounding on the PD, or induced current on a long outdoor run — rather than replacing switch hardware that was never actually damaged.
SYMPTOMLog shows Card burnt due to high PoE power; the switch comes back after a reseat, but the same fault reappears at unpredictable intervals.
CAUSEForeign debris created a short on the PoE power path, and the board proactively cut power output as a protective measure — a working self-defense mechanism, not proof the board itself is physically damaged.
FIXOpen the chassis (power confirmed off) and physically inspect for debris before concluding the board needs replacement; pull the power black-box log either way and keep the raw output for escalation if inspection doesn't resolve it.
SYMPTOMOne module alarms and recovers repeatedly, or one module shows several different alarm keywords, or every power module in the chassis alarms with the same code at once.
CAUSEEach pattern points somewhere different: a single module cycling between fault and recovery is itself unstable; a single module throwing multiple distinct alarm types usually means an external factor is hitting it, not an internal component failure; and every module alarming the same code at once is more likely a false alarm or a shared external cause than nine simultaneous hardware failures.
FIXPull the unstable module and escalate for the first two patterns; for the third, check the shared external supply and wiring before assuming every module needs replacing.
SYMPTOMA replacement power module slides in and locks in place, voltage at the source measures normal, and the chassis still won't power on.
CAUSEPower modules are pluggable, and a module from a different series can be physically compatible with the slot while not being on that chassis's supported module list.
FIXCheck the exact module part number against the product documentation's compatibility list before assuming a hardware fault on either the module or the chassis.
SYMPTOMVoltage checks out, the module is confirmed on the compatibility list, and the switch still won't power on.
CAUSEAt this point the fault is either in the specific power module or in the chassis itself, and no amount of re-reading the alarm log will tell you which — only a substitution test will.
FIXSwap in a power module known to be working correctly elsewhere; if the chassis powers on with it, the original module is faulty, if it doesn't, the fault has been isolated to the chassis.
Pulled straight from the field — the ones worth having an answer ready for.
Hiccup protection is a self-resetting lockout — the PoE chip senses leakage current, latches the power path shut to protect itself, and can come back once the switch is power-cycled and the leakage source is gone. A blown fuse in the protection circuit (the DC FUSE_FAULT condition) is a one-way hardware event on the monitor board itself, and it doesn't clear with a reseat — it needs the affected board or module physically reseated in a known-good slot to confirm, and replaced if that doesn't resolve it.
No — the black-box log records timestamped protection-state changes on the power module itself, not per-port diagnostic detail. For port-level leakage isolation, disconnect suspect ports one at a time and reseat the input power between attempts; the black-box log is what you hand to support alongside that isolation work, not a substitute for it.
That result narrows the fault to the chassis itself rather than the module. At that point collect the alarm history, the power black-box log if the module supports it, and the exact model and serial number, and escalate for a hardware evaluation rather than continuing to cycle power modules through the same slot.
For AC-input modules, 90V AC to 290V AC at the source. For DC-input modules, -38.4V DC to -72V DC. Measure with a multimeter at the actual input terminals, not just at a wall outlet upstream of any other equipment, since voltage drop along the run can put a reading that looks fine at the outlet out of range by the time it reaches the switch.
No. DC PWR_FAULT and DC PWR_LACK are input-side conditions — nothing or not enough is reaching the module. PWR PROTECT is the module's own protection circuit tripping in response to an internal over-temperature, over-current, over-voltage or under-voltage condition, or the input breaker simply not being closed — check the breaker first, since it's the fastest thing to rule out.
On chassis with more power modules installed than are strictly needed to carry the current load, yes — pull the faulty module, confirm the remaining modules are carrying the load within their rated capacity, and schedule the replacement rather than treating it as an immediate outage. On chassis running at or near full power-module capacity already, treat the replacement as urgent instead.
This note is built around the Huawei S-series box switch power fault-classification model, its display alarm / display power black-box log commands, and the field cases behind them. Exact LED names and alarm keywords vary slightly by power module wattage class and chassis series, but the underlying triage logic — reseat test, PoE chip protection versus internal short, external supply versus module versus chassis — carries over directly. It doesn't cover chassis-frame (modular) fan-tray power zoning in depth, or non-Huawei power module part numbers.
Tell us what the log shows after a reseat — PoE chip fault, Card burnt due to high PoE power, or nothing at all — plus the display alarm output, and we'll help you read it.