How to Clear LSI MegaRAID Hotspare Alarm After Rebuild Completion (9266-8i Controller)


2 views

After replacing a failed drive in our RAID 10 + hotspare configuration on LSI MegaRAID 9266-8i controllers, the system continues to emit an alarm beep (1 second on, 3 seconds off) during reboots. This specific pattern corresponds to SPEAKER_HOTSPARE_ENTRY in MegaRAID's alert system, indicating a hotspare has completed rebuilding but the controller still considers it an emergency spare.

The key evidence appears in the controller's event log:

MegaCli64 -AdpEventLog -GetEvents -f events.log -aALL
cat events.log

# Output shows:
Event Description: Global Hot Spare created on PD 08(e0xfc/s0) (global,rev)
Event Description: Reminder: Potential non-optimal configuration due to drive PD
                    08(e0xfc/s0) commissioned as emergency spare
  • Firmware update to latest version (mentioned in release notes for similar issues)
  • Standard hotspare replacement procedures
  • Controller cold reset

This requires manually clearing the emergency spare status and refreshing the configuration:

# First identify the physical drive ID
MegaCli64 -PDList -aALL | grep -A5 "PD 08"

# Remove the emergency spare flag
MegaCli64 -PDHSP -Rmv -PhysDrv[08] -a0

# Reconfigure as proper hotspare
MegaCli64 -PDHSP -Set -PhysDrv[08] -a0

# Verify configuration
MegaCli64 -LDInfo -LALL -aALL | grep -i "hot spare"

For automated monitoring, consider adding this to your health checks:

#!/bin/bash
ALERT_STATUS=$(MegaCli64 -AdpEventLog -GetEvents -Last24 -aALL | grep "emergency spare")
if [ -n "$ALERT_STATUS" ]; then
    echo "Emergency spare alert detected" | mail -s "RAID Alert" admin@example.com
fi

The controller maintains an internal flag for "emergency spare" even after rebuild completion. The -PDHSP commands force a state refresh, while the removal/recreation sequence ensures proper metadata updates.


When working with LSI MegaRAID 9266-8i controllers in Supermicro servers, you might encounter persistent beeping alarms after drive replacement - even after successful rebuilds. The 1-second-on/3-seconds-off beep pattern specifically indicates SPEAKER_HOTSPARE_ENTRY, signaling a completed rebuild but lingering alert state.

The key diagnostic command reveals two critical messages:

MegaCli64 -AdpEventLog -GetEvents -f events.log -aALL
cat events.log

# Output shows:
Event Description: Global Hot Spare created on PD 08(e0xfc/s0) (global,rev)
Event Description: Reminder: Potential non-optimal configuration due to drive PD
                 08(e0xfc/s0) commissioned as emergency spare

First, verify the current hotspare status:

MegaCli64 -PDHSP -List -aALL

To properly clear the alarm, you need to remove and recreate the hotspare assignment:

# Remove existing hotspare
MegaCli64 -PDHSP -Rmv -PhysDrv[8:0] -a0

# Recreate hotspare (if still needed)
MegaCli64 -PDHSP -Set -PhysDrv[8:0] -a0

The "Potential non-optimal configuration" warning often persists after firmware updates. Try these steps:

# Clear controller events (non-destructive)
MegaCli64 -AdpEventLog -Clear -aALL

# Optional: Rebuild the virtual drive manually
MegaCli64 -PDRbld -Start -PhysDrv[8:0] -a0

For scripted solutions, use these commands to manage the alarm:

# Temporarily silence alarm (until next reboot)
MegaCli64 -AdpSetProp AlarmSilence -VAL1 -aALL

# Permanently disable alarm (not recommended)
MegaCli64 -AdpSetProp AlarmDsbl -VAL1 -aALL

After making changes, verify with:

MegaCli64 -AdpEventLog -GetEvents -f events.log -aALL
MegaCli64 -AdpGetProp Alarm -aALL

Remember that the beeping pattern will continue until you either clear the event log or properly reconfigure the hotspare assignment. In production environments, consider implementing monitoring scripts to catch these conditions before they trigger alarms.