2011-03-02 01:55 AM
I installed a fabric MetroCluster with 3210 .
It tried SP version 1.1 and 1.2 .
Everything seems fine and the cluster functions normally but I've got a problem with the front panel LEDs ont the controllers .
On every controller , the warning led is blinking amber .
On one controller , The A led is Blinking Green .
On the other controller nor A or B are blinking .
The warning LED at the back of the controllers is blinking Amber .
Is it normal ?
I tried to power down controllers , reboot -s , ...
TIA , Reg/
Solved! SEE THE SOLUTION
2011-03-02 05:27 AM
After a FRU LED associated with a DIMM or PCIE slot has been turned on, the system
fault LED in the front and the controller fault LED in the rear will start
flashing every second. This may happen after the system has been powered down for a
long period of time, e.g. initial boot of the system.
1. At the Data ONTAP CLI prompt, halt the system with the "halt -s" command.
Warning: In an HA configuration, this will cause an HA takeover.
2. Wait for the controller to shut down and power off.
3. On the console port, press "Ctrl-G" to switch the console to the SP.
4. Log in to the SP.
5. At the SP prompt, enter the "system power on" command.
6. Press "Ctrl-D" to get back to the Data ONTAP console.
7. Once the BIOS/Loader have booted, enter the "boot_ontap" command.
If the condition persists after the workaround, you may need to swap out one or
more FRUs to clear the FRU LED condition.
2011-03-02 08:09 AM
I have hit this twice too and this procedure worked for the most part. It is documented under bugid (BURT) 472202. After the ctrl-g and "system power on" sometimes it locks up...but a power cycle after fixed it as well without ctrl-d (since we couldn't get the prompt in some cases).
Also make sure to check the environment variables per the TSB where bootarg init is set... these two options...setenv bootarg.init.wipeclean and setenv bootarg.init.console_muted ... I have seen cases where both are set and one other where only muted was set. Muted alone causes the setup script to run whenever there is a reboot, so unsetenv (or setenv opposite true/false setting) or set-defaults then bye to clear them... they are not something you want to leave set. It was caught in manufacturing and no new systems have it now, but I always printenv from the loader to make sure the options are not set on any new system (and especially before any head swap).