Has your system had a drive failure with a hot spare replace scenario?
If so, the firmware recognizes that a hot spare was used to replace a failed drive and that the system is beeping because it expects that the customer will wish to perform a copy back procedure to put the disk/slot order back into the original config. If the customer recreates the hot spare the beeping will cease, and the customer can then choose whether or not to do a copy back.
Copy back works like this:
1. Disk in slot one fails and hot spare drive in slot ten automatically starts to rebuild (this is called “commissioning” the hot spare). Beeping will continue during the rebuild unless silenced because the VD is degraded.
2. Rebuild completes and customer inserts a new drive into slot one. Beeping frequency changes to but continues because a hot spare does not yet exist and the configuration is not degraded, but is still not as original.
3. Customer makes disk in slot one the hot spare, beeping should stop and the customer should be prompted to perform a copy back procedure. In this procedure, the data is copied from the disk in slot ten to the disk in slot one, and the disk in slot ten becomes the hot spare drive; and the configuration is back to the original configuration.
Nope, the system never had a hotspare configured.
Apparently, the problem went away after a manual battery relearn cycle, so it must have been related to BBU. I still find it strange that there was no indication pointing to BBU whatsoever, but it seems solved for now.
You could use the CmdTool2 utility: CmdTool2 –AdpALILog –aAll > <filename>.txt to obtain SASLog file and see if there are any BBU error reports there.