2288H V5: Repeated RAID BBU Present / Absent Events
Source symptoms and comparison
The source concerns a 2288H V5 with a 3516 controller, identified in its event text as SP460C-M. SEL repeatedly reports BBU present/absent:
In the corresponding period, the controller’s own out-of-band event log records a single battery-present event:
The author concludes that the repeated SEL entries were false events for that case while the BBU was operating normally. Confirm current battery/controller health, cache policy and real event chronology; repeated presence events are not automatically harmless on every system.
Query-load correlation in the source
A management function queried the RAID controller once per minute. The source identifies this query, with its typographic dash normalized:
lsmcli -u megaraid:// list --type VOLUMES -sIt reports that the busy controller firmware returned 0x1001, prompting BMC to redetect BBU presence. On two systems where the customer stopped that polling, the repeated events stopped. This is a case correlation, not a universal prohibition on querying a RAID controller every minute.
Source event-masking example
The source treats these particular present/absent entries as detection events and offers immediate BMC-side event masking without a BMC restart. Masking changes visibility; it does not repair a failed BBU or prove that cache is protected. Prefer diagnosing the actual event and confirming the applicable firmware/polling remedy with the vendor.
For completeness, its two model/firmware-specific OEM raw examples are reproduced with the password removed. The remaining numeric bytes and example management address are retained. Do not use undocumented OEM payloads on another controller/BMC by analogy:
ipmitool.exe -I lanplus -H 192.168.2.100 -U Administrator -P <BMC_PASSWORD> raw 0x30 0x93 0xdb 0x07 0x00 0x35 0x49 0x00 0x01 0x00 0x00 0x00 0x07 0x00 0x75 0x04 0x3d 0x00 0x00 0x08 0x01 0x00 0x79 0x01 0x00
ipmitool.exe -I lanplus -H 192.168.2.100 -U Administrator -P <BMC_PASSWORD> raw 0x30 0x93 0xdb 0x07 0x00 0x35 0x49 0x00 0x01 0x00 0x00 0x00 0x07 0x00 0x75 0x04 0x3f 0x00 0x00 0x08 0x01 0x00 0x79 0x01 0x00The source says to use the Asserted event ID for the target condition, and describes 0x00 as disable and 0x01 as enable at its indicated control byte. The complete payload layout and inverse operation were not independently verified for other firmware; do not change an arbitrary 0x00 byte or assume a generic enable command. Confirm scope and restoration of required monitoring through the matching vendor procedure.