Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
I echo mark's thought... Specifically the elk firmware fixes this
Sent from my mobile phone
On Oct 7, 2014, at 7:02 AM, Mark Flint mf1@sanger.ac.uk wrote:
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
This does sound like a bug I (many of us) have ran into, however I thought with that bug that the issue was temporarily mitigated for a few months by a reboot. What version of ontap are you using?
Also, the auto shutdown is controlled by "options raid.timeout" and the value is hours. The shutdown is, however, to prevent you from losing data in a power outage or abrupt crash so consider the ramifications with extreme caution before extending. , --Jordan
FAS2240-X: Issue with NVMEM battery capacity and FCMTO error condition on FAS2240-X platform
KB ID: 2016695 Version: 9.0 Published date: 09/11/2014 Views: 6181
Symptoms
All FAS2240-X systems prior to March 2012 deliveries contain battery firmware which is susceptible to the FC-MTO issue.
There are several ways this issue can manifest, including warning and critical system notifications, depending on the level of charge in the battery.
Warning low limit is below 78-hr run-time:BATT_CAP_LOW Sun Nov 20 00:00:11 CET [befiler04: nvmem.battery.capacity.low.warn:info]: The NVMEM battery capacity is below normal.
Critical low limit is below 76-hr run-time: LOW_BATT Mon Nov 21 20:00:00 CET [befiler04: monitor.nvramLowBattery:CRITICAL]: NVRAM battery is dangerously low.
Mon Nov 21 20:00:00 CET [befiler04: monitor.nvramLowBattery.notice:notice]: If the NVRAM battery is dangerously low, the system shuts down automatically every 24 hours to encourage you to replace it. If you reboot the system it will run for another 24 hours before shutting down. (The 24 hour timeout may be increased by altering the "raid.timeout" value using the "options" command.)
Mon Nov 21 20:00:00 CET [befiler04: monitor.shutdown.nvramLowBattery.pending:warning]: NVRAM battery is dangerously low. Halting system in 24 hours. Replace the battery immediately!
Mon Nov 21 20:00:00 CET [befiler04: asup.throttle.drop:info]: Too many autosupport messages in too short a time, throttling autosupport: BATTERY_LOW
AutoSupport (ASUP) Verification of the Issue
ASUP messages from a system can be reviewed to determine the status of the NVMEM battery related to this issue:
If the system has detected a 'warning low' or 'critical low battery' condition, the ENVIRONMENT section of the system ASUP will contain battery sensor details. A symptom for this issue can be with the message that either the 'run-time' is less than '78-hr Warning' or less than '76-hr Critical'. Systems above 78 hr run time will not produce a message. A coupled symptom is that the 'Bat Curr' = 0mA. The charger should be ON based on the battery being at a low capacity level, but the sensor indicates that there is no current going into the battery. The last symptom for this issue is 'Charger Volt' displays 0V. In a normal operation, it should always be reported as 8200 mV. Bat 1.5V normal 1496 mV 1277 mV 1341 mV 1651 mV 1728 mV Bat 8.0V normal 7900 mV -- -- 8600 mV 8700 mV Bat Curr normal 0 mA -- -- 800 mA 900 mA Bat Capacity normal 2304 mA*hr -- -- -- -- Bat Run Time normal 140 hr 76 hr 78 hr -- -- Bat Temp normal 27 C 0 C 10 C 55 C 64 C Charger Curr normal 0 mA -- -- 2200 mA 2300 mA Charger Cycle normal 0 cycles -- -- -- -- Charger Volt normal 0 mV -- -- 8600 mV 8700 mV
Sometimes, the only information provided in the Environment section of the ASUP is: Battery: Sensor Bat_Run_Time warning low: current custom is 78 , critical low is 76 , normal low is 78 Systems not on AutoSupport can be interrogated using the SP command system sensors. The details can be found in the procedure provided. Scope of Affected Systems: All FAS2240-X systems batteries delivered prior to March 2012 will be affected.
Cause
This message is sent as long as the battery is below the minimum safe voltage required to protect the data in the event of a power failure or an unexpected shutdown.
Solution
The customer system battery firmware revision should be identified to confirm a firmware update is required. Follow steps 1-5 of the Flashing the Battery Firmware to confirm an update to the battery firmware is required.
There are 2 parts to this procedure, Flashing the Battery Firmware and Resetting the FC-MTO flag. The FC-MTO flag issue can be confirmed by following the steps 1-5 of the Resetting the FC-MTO flag procedure. For systems which have not encountered the FC-MTO flag issue, there is no need to perform the Resetting the FC-MTO flag procedure. There are two scenarios for systems:
Note: Flashing the Battery Firmware does not clear the FC-MTO flag.
Systems which have the FC-MTO flag set condition: Actions: Flash the battery Firmware and Reset the FC-MTO flag. Systems which do not have the FC-MTO flag issue: Actions: Verify the FC-MTO flag issue is not present in the system and flash the battery firmware. Notes:
The battery firmware update must be performed prior to resetting the FC-MTO flag. This is a disruptive procedure and will require system downtime. For HA systems, a takeover and giveback should be managed in conjunction with the system halt required for this procedure and this may reduce the operational impacts of this procedure for some customers. Follow the instructions on the NetApp Support Site to save the two Battery Firmware Files: battery-27100029-nexergy.i and battery-27100029-energysales.i to the <Battery_Firmware_File_Location>.identified on the customer’s Web server. They are in a zipped package located at this link: Battery Firmware 27100029 A working FAS2240-X system with HTTP server connectivity through the management (SP) port is required. Identify a location accessible from the management port of the affected system we will refer to as <Battery_Firmware_File_Location>. This URL must be less than 100 characters.
Important: A FAS22XX system with network connectivity through an SP port is required. A Web server is also required to apply the battery firmware update. Download the updated firmware from the NetApp Support site, extract the files from the archive, and place the files on a Web server in a subnet that is accessible by the Service Processor. We will refer to this location as <Battery_Firmware_File_Location>. This URL location must be less than 100 characters.
Instructions to enable the SP port (if not currently set up)
Perform the following steps:
Connect a network cable to the FAS2240-X system management port. Set up SP with a static IP address. Note: This can be set up either from either Data ONTAP or LOADER. 7-Mode: ontap> sp setup Clustered Data ONTAP: ontap> system node run -node -command sp setup
The Service Processor (SP) provides remote management capabilities including console redirection, logging and power control.
It also extends AutoSupport by sending additional system event alerts. Your AutoSupport settings are used for sending these alerts through e-mail over the SP LAN interface.
Would you like to configure the SP? yes Would you like to enable DHCP on the SP LAN interface? no Enter the IP address for the SP [ ]: 192.168.30.243 Enter the netmask for the SP [ ]:255.255.254.0 Enter the IP address for the SP gateway []:192.168.30.1 Do you want to enable IPv6 on the SP ? no
Flashing the Battery Firmware
Note: User 'naroot' is disabled in Clustered Data ONTAP 8.1 and later. User must create an SP admin user account to login. This is a pre-requisite before shutting down Data ONTAP.
Perform the following steps:
Use the following command to halt the system: Data ONTAP 7-Mode : ontap> halt Clustered Data ONTAP : ontap> system node halt -node <local node name>
1a. Alternatively, a cf takeover can be executed from the partner node in a clustered configuration. From the partner controller, run the following command: However, before doing that, ensure autogiveback is not enabled (that is, ON).
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable Clustered Data ONTAP : partner_ontap(node2)> run -node <node2> -command options cf.giveback.auto.enable
If enabled, then:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable off Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback false Data ONTAP 7-Mode : partner_ontap> cf takeover Clustered Data ONTAP : partner_ontap(node2)> storage failover takeover -ofnode <local node(node1)>
If AUTOBOOT environment variable was set to TRUE, the local node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt. Use CTRL+c to abort waiting and halt the node. Enter ‘y’ when the system prompts Do you wish to halt this node rather than wait [y/n]?
Log in to the SP CLI by using CTRL+G: LOADER>. CTRL+G 2a. Optional method to access the SP shell: Use SSH to the SP interface to get to the SP CLI for issuing commands.
At the Service Processor login prompt, use SP admin user account credentials to login. Example: ‘naroot’ for 7-Mode and ‘admin’ or ‘SP user with admin privileges’ for Clustered Data ONTAP. Switching console to Service Processor Service Processor Login: naroot
Enable diagnostic privileges and display the battery information: SP>priv set diag
Confirm the battery vendor (EnergySales or Nexergy) and check the rev_hardware values.
Note: If the rev_hardware is 0x00a3 or higher, the battery firmware already has the FC-MTO related change. In this case, do not upgrade the battery firmware as these batteries are already updated. SP*>system battery show
chemistry : LION device-name : bq20z78 expected-load-mw : 133 id : 27100029 manufacturer : EnergySales manufacturer-date : 4/4/2010 rev_cell : 0x0000 rev_firmware : 0x0100 rev_hardware : 0x00a1 TI_fw_version : 0x0110 TI_hw_version : 0xa2 serial : 0x0001 status : ready
Flash the battery firmware onto the battery. Use the correct battery firmware file: battery-27100029-nexergy.i or battery-27100029-energysales.i depending on the manufacturer identified in step 5. You will see the confirmation Battery firmware update completed. when the operation completed successfully. For Energy Sales Batteries:
SP*> system battery flash http://<Battery_Firmware_File_Location>battery-27100029-energysales.i Downloading battery firmware image ... Successful Accessing battery ... Flashing 27100029-EnergySales battery FW revision from 'a1' to 'a3' ... done Disabled battery auto update after manual firmware flash Battery firmware update completed.
-OR-
For Nexergy Batteries:
SP*> system battery flash http://<Battery_Firmware_File_Location>battery-27100029-nexergy.i Downloading battery firmware image ... Successful Accessing battery ... Flashing 27100029-Nexergy battery FW revision from 'a1' to 'a3' ... done Disabled battery auto update after manual firmware flash Battery firmware update completed.
Perform battery verify. You will see the message Verify test passed when the operation completed successfully.
For Energy Sales Batteries:
SP*> system battery verify http://<Battery_Firmware_File_Location>battery-27100029-energysales.i Downloading battery firmware image ... Successful Verify test passed -OR-
For Nexergy Batteries:
SP*> system battery verify http://<Battery_Firmware_File_Location>battery-27100029-nexergy.i Downloading battery firmware image ... Successful Verify test passed
Verify the rev_hardware has changed to 0x00a3.
SP*> system battery show chemistry : LION device-name : bq20z78 expected-load-mw : 133 id : 27100029 manufacturer : EnergySales manufacturer-date : 4/4/2010 rev_cell : 0x0000 rev_firmware : 0x0100 rev_hardware : 0x00a3 TI_fw_version : 0x0110 TI_hw_version : 0xa2 serial : 0x0001 status : ready
Exit SP shell, (if SSH was used to access the SP, connect to the system console port). SP*>CTRL-D to exit SP shell Boot ONTAP LOADER> boot_ontap
On a cluster system, when the node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt, perform a giveback from partner node. Data ONTAP 7-Mode : partner_ontap> cf giveback Clustered Data ONTAP : partner_ontap(node2)> storage failover giveback -ofnode <local node(node1)>
Resetting the FC-MTO flag
Enter the SP shell. ontap> CTRL-G 1a. Optional method to access the SP shell: Use SSH to the SP interface to get to the SP CLI for issuing commands.
At the Service Processor login prompt, use SP admin user account credentials to login. Example: ‘naroot’ for 7-Mode and ‘admin’ or ‘SP user with admin privileges’ for Clustered Data ONTAP.
Switching console to Service Processor Service Processor Login: naroot
Run the following command on SP CLI to display sensor information: SP*> system sensors Sensor Name | Current | Unit | Status | LCR | LNC | UNC | UCR ---------------+---------+-------------+--------+--------+--------+--------+-----------
Bat_1.5V | 1.509 | Volts | ok | 1.277 | 1.342 | 1.651 | 1.729 Bat_8.0V | 8.100 | Volts | ok | na | na | 8.600 | 8.700 Bat_Curr | 0.000 | Amps | ok | na | na | 0.800 | 0.900 Bat_Capacity | 2.048 | Amps * hour | ok | na | na | na | na Bat_Run_Time | 136.000 | hour | ok | 76.000 | 78.000 | na | na Bat_Temp | 29.000 | degrees C | ok | 0.000 | 10.000 | 55.000 | 64.000 Charger_Curr | 0.000 | Amps | ok | na | na | 2.200 | 2.300 Charger_Cycles | 4.000 | cycles | ok | na | na | 250.000| 251.000 Charger_Volt | 0.000 | Volts | ok | na | na | 8.600 | 8.700
Check if 'Bat_Run_Time' is below 78-hr Warning or below 76-hr Critical. Confirm that 'Bat_Curr' = 0 mA and 'Charger_Volt' = 0 mV. For systems below 76-hr Critical Low threshold – LOW_BATT, take immediate action. The shutdown sequence has begun. For systems below 78-hr but > 76-hr 'run time,' there is some time prior to initiating the shutdown sequence. Under normal conditions, a typical battery can take up to 14 days to decrease from 78 to 76-hr run time. Press CTRL-D to exit SP shell (if SSH was used to access the SP, connect to the system console port). Note: The following steps need to be performed during a scheduled maintenance window:
Use the following command to halt the system: Data ONTAP 7-Mode : ontap> halt Clustered Data ONTAP : ontap> system node halt -node <local node name>
6a. Alternatively, a cf takeover can be executed from the partner node in a clustered configuration. From the partner controller, run the following command: However, before doing that, ensure autogiveback is not enabled (ON).
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable Clustered Data ONTAP : partner_ontap(node2)> run -node <node2> -command options cf.giveback.auto.enable
If enabled, then:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable off Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback false Data ONTAP 7-Mode : partner_ontap> cf takeover Clustered Data ONTAP : partner_ontap(node2)> storage failover takeover -ofnode <local node(node1)>
If AUTOBOOT environment variable was set to TRUE, the local node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt. Use CTRL+c to abort waiting and halt the node. Enter ’y’ when the system prompts Do you wish to halt this node rather than wait [y/n]?
Enter Maintenance Mode. While booting Data ONTAP when the CTL-C message appears, press <CTL-C> to interrupt the boot process LOADER> boot_ontap Select 5 as the maintenance mode boot method. Clear the 'no charger' condition by running the following command: *> halt Recover the system by running the following command: LOADER> boot_ontap For systems with less than 76 hr 'runtime,' the system will not boot Data ONTAP until the battery has charged to a minimum of 76 hr 'runtime' is reached. This is usually achieved in a few minutes, the command CTRL+G could be used to bypass the wait period depending on the customer environment. Note: If the wait period is bypassed, the warning messages will continue until the battery is sufficiently charged beyond the 76 hour threshold.
9a. If a takeover was performed per step 6a, the controller will boot to waiting for giveback. From the partner controller, run the following command:
Data ONTAP 7-Mode : partner_ontap> cf giveback Clustered Data ONTAP: partner_ontap(node2)> storage failover giveback -ofnode <local node(node1)>
Enter the SP shell, as indicated in step 2. Confirm the battery status by executing the system sensors command, as indicated in step 2. Verify that 'Charger_Volt' is 8200 mV and there is 'Bat_Curr' >0 mA (if the battery needs to be charged). If the battery is fully charged, 'Bat_Curr' will be 0mA and 'Charger_Volt' will be 8.200 V. Recheck 'Bat_Run_Time.' this value should be increasing. For systems which did not reach 76 hr 'runtime' threshold, the battery should recover and the warning messages will discontinue. Press CTRL-D to exit SP shell (if SSH was used to access the SP, connect to the system console port). Restore auto giveback option to original state:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable <on | off> Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback <true | false>
Related Links:
TSB 1112-01 BUG 536445 2016592: FAS32XX/V32XX/SA320: Issue with NVMEM battery capacity and FCMTO error condition
Disclaimer
NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Mike Gossett Sent: Tuesday, October 07, 2014 8:18 AM To: Mark Flint Cc: Toasters@teaparty.net Subject: Re: Question regarding NVRAM battery
I echo mark's thought... Specifically the elk firmware fixes this
Sent from my mobile phone
On Oct 7, 2014, at 7:02 AM, Mark Flint mf1@sanger.ac.uk wrote:
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Looks like this is not regarding FAS2040…
I am very intrigued, all of ours FAS2020, FAS2020a, have the same sensors show for charger amp 0ma.
The only one which is not charging is this specific controller, could it a chassis issue? power supply is ok as stated on the tests…
Any help would be very much appreciated.
On Oct 7, 2014, at 11:21 AM, Jordan Slingerland Jordan.Slingerland@independenthealth.com wrote:
This does sound like a bug I (many of us) have ran into, however I thought with that bug that the issue was temporarily mitigated for a few months by a reboot. What version of ontap are you using?
Also, the auto shutdown is controlled by "options raid.timeout" and the value is hours. The shutdown is, however, to prevent you from losing data in a power outage or abrupt crash so consider the ramifications with extreme caution before extending. , --Jordan
FAS2240-X: Issue with NVMEM battery capacity and FCMTO error condition on FAS2240-X platform
KB ID: 2016695 Version: 9.0 Published date: 09/11/2014 Views: 6181
Symptoms
All FAS2240-X systems prior to March 2012 deliveries contain battery firmware which is susceptible to the FC-MTO issue.
There are several ways this issue can manifest, including warning and critical system notifications, depending on the level of charge in the battery.
Warning low limit is below 78-hr run-time:BATT_CAP_LOW Sun Nov 20 00:00:11 CET [befiler04: nvmem.battery.capacity.low.warn:info]: The NVMEM battery capacity is below normal.
Critical low limit is below 76-hr run-time: LOW_BATT Mon Nov 21 20:00:00 CET [befiler04: monitor.nvramLowBattery:CRITICAL]: NVRAM battery is dangerously low.
Mon Nov 21 20:00:00 CET [befiler04: monitor.nvramLowBattery.notice:notice]: If the NVRAM battery is dangerously low, the system shuts down automatically every 24 hours to encourage you to replace it. If you reboot the system it will run for another 24 hours before shutting down. (The 24 hour timeout may be increased by altering the "raid.timeout" value using the "options" command.)
Mon Nov 21 20:00:00 CET [befiler04: monitor.shutdown.nvramLowBattery.pending:warning]: NVRAM battery is dangerously low. Halting system in 24 hours. Replace the battery immediately!
Mon Nov 21 20:00:00 CET [befiler04: asup.throttle.drop:info]: Too many autosupport messages in too short a time, throttling autosupport: BATTERY_LOW
AutoSupport (ASUP) Verification of the Issue
ASUP messages from a system can be reviewed to determine the status of the NVMEM battery related to this issue:
If the system has detected a 'warning low' or 'critical low battery' condition, the ENVIRONMENT section of the system ASUP will contain battery sensor details. A symptom for this issue can be with the message that either the 'run-time' is less than '78-hr Warning' or less than '76-hr Critical'. Systems above 78 hr run time will not produce a message. A coupled symptom is that the 'Bat Curr' = 0mA. The charger should be ON based on the battery being at a low capacity level, but the sensor indicates that there is no current going into the battery. The last symptom for this issue is 'Charger Volt' displays 0V. In a normal operation, it should always be reported as 8200 mV. Bat 1.5V normal 1496 mV 1277 mV 1341 mV 1651 mV 1728 mV Bat 8.0V normal 7900 mV -- -- 8600 mV 8700 mV Bat Curr normal 0 mA -- -- 800 mA 900 mA Bat Capacity normal 2304 mA*hr -- -- -- -- Bat Run Time normal 140 hr 76 hr 78 hr -- -- Bat Temp normal 27 C 0 C 10 C 55 C 64 C Charger Curr normal 0 mA -- -- 2200 mA 2300 mA Charger Cycle normal 0 cycles -- -- -- -- Charger Volt normal 0 mV -- -- 8600 mV 8700 mV
Sometimes, the only information provided in the Environment section of the ASUP is: Battery: Sensor Bat_Run_Time warning low: current custom is 78 , critical low is 76 , normal low is 78 Systems not on AutoSupport can be interrogated using the SP command system sensors. The details can be found in the procedure provided. Scope of Affected Systems: All FAS2240-X systems batteries delivered prior to March 2012 will be affected.
Cause
This message is sent as long as the battery is below the minimum safe voltage required to protect the data in the event of a power failure or an unexpected shutdown.
Solution
The customer system battery firmware revision should be identified to confirm a firmware update is required. Follow steps 1-5 of the Flashing the Battery Firmware to confirm an update to the battery firmware is required.
There are 2 parts to this procedure, Flashing the Battery Firmware and Resetting the FC-MTO flag. The FC-MTO flag issue can be confirmed by following the steps 1-5 of the Resetting the FC-MTO flag procedure. For systems which have not encountered the FC-MTO flag issue, there is no need to perform the Resetting the FC-MTO flag procedure. There are two scenarios for systems:
Note: Flashing the Battery Firmware does not clear the FC-MTO flag.
Systems which have the FC-MTO flag set condition: Actions: Flash the battery Firmware and Reset the FC-MTO flag. Systems which do not have the FC-MTO flag issue: Actions: Verify the FC-MTO flag issue is not present in the system and flash the battery firmware. Notes:
The battery firmware update must be performed prior to resetting the FC-MTO flag. This is a disruptive procedure and will require system downtime. For HA systems, a takeover and giveback should be managed in conjunction with the system halt required for this procedure and this may reduce the operational impacts of this procedure for some customers. Follow the instructions on the NetApp Support Site to save the two Battery Firmware Files: battery-27100029-nexergy.i and battery-27100029-energysales.i to the <Battery_Firmware_File_Location>.identified on the customer’s Web server. They are in a zipped package located at this link: Battery Firmware 27100029 A working FAS2240-X system with HTTP server connectivity through the management (SP) port is required. Identify a location accessible from the management port of the affected system we will refer to as <Battery_Firmware_File_Location>. This URL must be less than 100 characters.
Important: A FAS22XX system with network connectivity through an SP port is required. A Web server is also required to apply the battery firmware update. Download the updated firmware from the NetApp Support site, extract the files from the archive, and place the files on a Web server in a subnet that is accessible by the Service Processor. We will refer to this location as <Battery_Firmware_File_Location>. This URL location must be less than 100 characters.
Instructions to enable the SP port (if not currently set up)
Perform the following steps:
Connect a network cable to the FAS2240-X system management port. Set up SP with a static IP address. Note: This can be set up either from either Data ONTAP or LOADER. 7-Mode: ontap> sp setup Clustered Data ONTAP: ontap> system node run -node -command sp setup
The Service Processor (SP) provides remote management capabilities including console redirection, logging and power control.
It also extends AutoSupport by sending additional system event alerts. Your AutoSupport settings are used for sending these alerts through e-mail over the SP LAN interface.
Would you like to configure the SP? yes Would you like to enable DHCP on the SP LAN interface? no Enter the IP address for the SP [ ]: 192.168.30.243 Enter the netmask for the SP [ ]:255.255.254.0 Enter the IP address for the SP gateway []:192.168.30.1 Do you want to enable IPv6 on the SP ? no
Flashing the Battery Firmware
Note: User 'naroot' is disabled in Clustered Data ONTAP 8.1 and later. User must create an SP admin user account to login. This is a pre-requisite before shutting down Data ONTAP.
Perform the following steps:
Use the following command to halt the system: Data ONTAP 7-Mode : ontap> halt Clustered Data ONTAP : ontap> system node halt -node <local node name>
1a. Alternatively, a cf takeover can be executed from the partner node in a clustered configuration. From the partner controller, run the following command: However, before doing that, ensure autogiveback is not enabled (that is, ON).
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable Clustered Data ONTAP : partner_ontap(node2)> run -node <node2> -command options cf.giveback.auto.enable
If enabled, then:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable off Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback false Data ONTAP 7-Mode : partner_ontap> cf takeover Clustered Data ONTAP : partner_ontap(node2)> storage failover takeover -ofnode <local node(node1)>
If AUTOBOOT environment variable was set to TRUE, the local node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt. Use CTRL+c to abort waiting and halt the node. Enter ‘y’ when the system prompts Do you wish to halt this node rather than wait [y/n]?
Log in to the SP CLI by using CTRL+G: LOADER>. CTRL+G 2a. Optional method to access the SP shell: Use SSH to the SP interface to get to the SP CLI for issuing commands.
At the Service Processor login prompt, use SP admin user account credentials to login. Example: ‘naroot’ for 7-Mode and ‘admin’ or ‘SP user with admin privileges’ for Clustered Data ONTAP. Switching console to Service Processor Service Processor Login: naroot
Enable diagnostic privileges and display the battery information: SP>priv set diag
Confirm the battery vendor (EnergySales or Nexergy) and check the rev_hardware values.
Note: If the rev_hardware is 0x00a3 or higher, the battery firmware already has the FC-MTO related change. In this case, do not upgrade the battery firmware as these batteries are already updated. SP*>system battery show
chemistry : LION device-name : bq20z78 expected-load-mw : 133 id : 27100029 manufacturer : EnergySales manufacturer-date : 4/4/2010 rev_cell : 0x0000 rev_firmware : 0x0100 rev_hardware : 0x00a1 TI_fw_version : 0x0110 TI_hw_version : 0xa2 serial : 0x0001 status : ready
Flash the battery firmware onto the battery. Use the correct battery firmware file: battery-27100029-nexergy.i or battery-27100029-energysales.i depending on the manufacturer identified in step 5. You will see the confirmation Battery firmware update completed. when the operation completed successfully. For Energy Sales Batteries:
SP*> system battery flash http://<Battery_Firmware_File_Location>battery-27100029-energysales.i Downloading battery firmware image ... Successful Accessing battery ... Flashing 27100029-EnergySales battery FW revision from 'a1' to 'a3' ... done Disabled battery auto update after manual firmware flash Battery firmware update completed.
-OR-
For Nexergy Batteries:
SP*> system battery flash http://<Battery_Firmware_File_Location>battery-27100029-nexergy.i Downloading battery firmware image ... Successful Accessing battery ... Flashing 27100029-Nexergy battery FW revision from 'a1' to 'a3' ... done Disabled battery auto update after manual firmware flash Battery firmware update completed.
Perform battery verify. You will see the message Verify test passed when the operation completed successfully.
For Energy Sales Batteries:
SP*> system battery verify http://<Battery_Firmware_File_Location>battery-27100029-energysales.i Downloading battery firmware image ... Successful Verify test passed -OR-
For Nexergy Batteries:
SP*> system battery verify http://<Battery_Firmware_File_Location>battery-27100029-nexergy.i Downloading battery firmware image ... Successful Verify test passed
Verify the rev_hardware has changed to 0x00a3.
SP*> system battery show chemistry : LION device-name : bq20z78 expected-load-mw : 133 id : 27100029 manufacturer : EnergySales manufacturer-date : 4/4/2010 rev_cell : 0x0000 rev_firmware : 0x0100 rev_hardware : 0x00a3 TI_fw_version : 0x0110 TI_hw_version : 0xa2 serial : 0x0001 status : ready
Exit SP shell, (if SSH was used to access the SP, connect to the system console port). SP*>CTRL-D to exit SP shell Boot ONTAP LOADER> boot_ontap
On a cluster system, when the node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt, perform a giveback from partner node. Data ONTAP 7-Mode : partner_ontap> cf giveback Clustered Data ONTAP : partner_ontap(node2)> storage failover giveback -ofnode <local node(node1)>
Resetting the FC-MTO flag
Enter the SP shell. ontap> CTRL-G 1a. Optional method to access the SP shell: Use SSH to the SP interface to get to the SP CLI for issuing commands.
At the Service Processor login prompt, use SP admin user account credentials to login. Example: ‘naroot’ for 7-Mode and ‘admin’ or ‘SP user with admin privileges’ for Clustered Data ONTAP.
Switching console to Service Processor Service Processor Login: naroot
Run the following command on SP CLI to display sensor information: SP*> system sensors Sensor Name | Current | Unit | Status | LCR | LNC | UNC | UCR ---------------+---------+-------------+--------+--------+--------+--------+-----------
Bat_1.5V | 1.509 | Volts | ok | 1.277 | 1.342 | 1.651 | 1.729 Bat_8.0V | 8.100 | Volts | ok | na | na | 8.600 | 8.700 Bat_Curr | 0.000 | Amps | ok | na | na | 0.800 | 0.900 Bat_Capacity | 2.048 | Amps * hour | ok | na | na | na | na Bat_Run_Time | 136.000 | hour | ok | 76.000 | 78.000 | na | na Bat_Temp | 29.000 | degrees C | ok | 0.000 | 10.000 | 55.000 | 64.000 Charger_Curr | 0.000 | Amps | ok | na | na | 2.200 | 2.300 Charger_Cycles | 4.000 | cycles | ok | na | na | 250.000| 251.000 Charger_Volt | 0.000 | Volts | ok | na | na | 8.600 | 8.700
Check if 'Bat_Run_Time' is below 78-hr Warning or below 76-hr Critical. Confirm that 'Bat_Curr' = 0 mA and 'Charger_Volt' = 0 mV. For systems below 76-hr Critical Low threshold – LOW_BATT, take immediate action. The shutdown sequence has begun. For systems below 78-hr but > 76-hr 'run time,' there is some time prior to initiating the shutdown sequence. Under normal conditions, a typical battery can take up to 14 days to decrease from 78 to 76-hr run time. Press CTRL-D to exit SP shell (if SSH was used to access the SP, connect to the system console port). Note: The following steps need to be performed during a scheduled maintenance window:
Use the following command to halt the system: Data ONTAP 7-Mode : ontap> halt Clustered Data ONTAP : ontap> system node halt -node <local node name>
6a. Alternatively, a cf takeover can be executed from the partner node in a clustered configuration. From the partner controller, run the following command: However, before doing that, ensure autogiveback is not enabled (ON).
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable Clustered Data ONTAP : partner_ontap(node2)> run -node <node2> -command options cf.giveback.auto.enable
If enabled, then:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable off Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback false Data ONTAP 7-Mode : partner_ontap> cf takeover Clustered Data ONTAP : partner_ontap(node2)> storage failover takeover -ofnode <local node(node1)>
If AUTOBOOT environment variable was set to TRUE, the local node boots to Waiting for giveback...(Press Ctrl-C to abort wait) prompt. Use CTRL+c to abort waiting and halt the node. Enter ’y’ when the system prompts Do you wish to halt this node rather than wait [y/n]?
Enter Maintenance Mode. While booting Data ONTAP when the CTL-C message appears, press <CTL-C> to interrupt the boot process LOADER> boot_ontap Select 5 as the maintenance mode boot method. Clear the 'no charger' condition by running the following command: *> halt Recover the system by running the following command: LOADER> boot_ontap For systems with less than 76 hr 'runtime,' the system will not boot Data ONTAP until the battery has charged to a minimum of 76 hr 'runtime' is reached. This is usually achieved in a few minutes, the command CTRL+G could be used to bypass the wait period depending on the customer environment. Note: If the wait period is bypassed, the warning messages will continue until the battery is sufficiently charged beyond the 76 hour threshold.
9a. If a takeover was performed per step 6a, the controller will boot to waiting for giveback. From the partner controller, run the following command:
Data ONTAP 7-Mode : partner_ontap> cf giveback Clustered Data ONTAP: partner_ontap(node2)> storage failover giveback -ofnode <local node(node1)>
Enter the SP shell, as indicated in step 2. Confirm the battery status by executing the system sensors command, as indicated in step 2. Verify that 'Charger_Volt' is 8200 mV and there is 'Bat_Curr' >0 mA (if the battery needs to be charged). If the battery is fully charged, 'Bat_Curr' will be 0mA and 'Charger_Volt' will be 8.200 V. Recheck 'Bat_Run_Time.' this value should be increasing. For systems which did not reach 76 hr 'runtime' threshold, the battery should recover and the warning messages will discontinue. Press CTRL-D to exit SP shell (if SSH was used to access the SP, connect to the system console port). Restore auto giveback option to original state:
Data ONTAP 7-Mode : partner_ontap> options cf.giveback.auto.enable <on | off> Clustered Data ONTAP : partner_ontap(node2)> storage failover modify -node <local node(node2)> -auto-giveback <true | false>
Related Links:
TSB 1112-01 BUG 536445 2016592: FAS32XX/V32XX/SA320: Issue with NVMEM battery capacity and FCMTO error condition
Disclaimer
NetApp provides no representations or warranties regarding the accuracy, reliability, or serviceability of any information or recommendations provided in this publication, or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS, and the use of this information or the implementation of any recommendations or techniques herein is a customer’s responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Mike Gossett Sent: Tuesday, October 07, 2014 8:18 AM To: Mark Flint Cc: Toasters@teaparty.net Subject: Re: Question regarding NVRAM battery
I echo mark's thought... Specifically the elk firmware fixes this
Sent from my mobile phone
On Oct 7, 2014, at 7:02 AM, Mark Flint mf1@sanger.ac.uk wrote:
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Wasn’t this bug only with FAS32x0?
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Mike Gossett Sent: Wednesday, 8 October 2014 1:18 a.m. To: Mark Flint Cc: Toasters@teaparty.net Subject: Re: Question regarding NVRAM battery
I echo mark's thought... Specifically the elk firmware fixes this
Sent from my mobile phone
On Oct 7, 2014, at 7:02 AM, Mark Flint mf1@sanger.ac.uk wrote:
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Disclaimer
The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu New Zealand Limited on 4 4950700 or by reply e-mail to the sender and delete the document and all copies thereof.
Whereas Fujitsu New Zealand Limited would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu New Zealand Limited does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.
If you do not wish to receive commercial and/or marketing email messages from Fujitsu New Zealand Limited, please email unsubscribe@nz.fujitsu.com
That may be true as that is where I encountered the similar issue a few others described, though being that the 7.3.7 a similar bug is not out of the question from my prospective. Updating the RLM/SP/BMC does sounds like a good start (like Mark said) ..also getting to something higher than 7.3.7 might also be a good idea, though my guess is there is something holding him back.
--Jordan
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Bradley, Shane Sent: Tuesday, October 07, 2014 10:46 PM To: Mike Gossett; Mark Flint Cc: Toasters@teaparty.net Subject: RE: Question regarding NVRAM battery
Wasn’t this bug only with FAS32x0?
-----Original Message----- From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Mike Gossett Sent: Wednesday, 8 October 2014 1:18 a.m. To: Mark Flint Cc: Toasters@teaparty.net Subject: Re: Question regarding NVRAM battery
I echo mark's thought... Specifically the elk firmware fixes this
Sent from my mobile phone
On Oct 7, 2014, at 7:02 AM, Mark Flint mf1@sanger.ac.uk wrote:
Sounds like the battery firmware bug from a while ago. You’ll need to update your battery firmware, and possibly the RLP/SP firmware as well (no experience of the 2xxx series ) There are knowledge base articles available, do you have access?
Mark Flint mf1@sanger.ac.uk
On 7 Oct 2014, at 12:07, Camillo Gornati cams1976@gmail.com wrote:
Hello all!
We have 4 net app systems a FAS2020, 2 x FAS2020a and one FAS2040.
The FAS2040 had a NVRAM battery losing power until it shut down because of the battery not having power.
Purchased a battery, replaced, and still no charge.
Now we though the problem was the controller, so i purchased a new controller, replaced CF CARD and inserted back in the chassis, noticed battery wasn’t charging either, now controller has shut down again and battery is not charging.
Could someone give me a light on this one?
Firmware issue?
Thanks again!
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE.
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
Disclaimer
The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu New Zealand Limited on 4 4950700 or by reply e-mail to the sender and delete the document and all copies thereof.
Whereas Fujitsu New Zealand Limited would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu New Zealand Limited does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached.
If you do not wish to receive commercial and/or marketing email messages from Fujitsu New Zealand Limited, please email unsubscribe@nz.fujitsu.com
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-
Bradley, Shane -
Camillo Gornati -
Jordan Slingerland -
Mark Flint -
Mike Gossett