Start a Conversation

Unsolved

This post is more than 5 years old

J

1101811

January 17th, 2007 11:00

E1211 ROMB battery failes perc 5/i

Several 1950 and 2950 servers give on display E1211 ROMB battery failures. These new servers were offline for several months.

When I start-up the server is showing “The battery hardware is missing or malfunctioning, or the battery is unplugged. If you continue to boot the system, the battery-backed cache will not function. Please contact technical support for assistance.”

I left the server on for several days but the error doesn’t disappear. When I switch the battery from another server this server is ok but the other fails. Seems to me battery doesn’t recharge anymore.

 

Is there another solution because now it seems the spare servers have to stay online.

 

Regards Jos

January 25th, 2007 22:00

Same problem here with 5 servers..
Have you been able to correct the problem ?

3 Posts

January 26th, 2007 05:00

No, I just replace batteries.

Dell suggests disconnecting the battery until you use the server.

January 26th, 2007 16:00

I Contacted Dell.
They will be sending the batteries next monday.
 
Thanks
Alex

January 26th, 2007 17:00

Hello, I'm new to this Dell site and im just trying to figure out how to talk to people.  Just curious if you recieve this message then i know i found a way in.  I have a optiplex myself and so far things are running okay.  It was a challenge at first though.  If i reach you i would just like to wish you all the luck with your machine.  thanks,
 

2 Posts

February 20th, 2007 22:00

**Updated 2/26/2007
 
Dells support solution did not work. Apparently if the servers sit for too long, the batteries go south and no amount of charging will recover them.
 

 
Dell support recommends the following.
 
The batteries are not fully charged when shipped. If the server is powered up with depleted batteries, the batteries will NOT charge.
 
To charge the batteries initially, plug the server in but do not power it up.
 
Dell is recommending that the server stay powered down and plugged in for 48 hours to initially charge the batteries.
 
Once the initial charge is completed, the server will maintain the battery charge while powered up.


Message Edited by darusko on 02-26-2007 06:10 PM

1 Message

January 22nd, 2010 06:00

I followed the above procedure but still get the same error message. Could the problem be beyond the RAID battery - like a defective charging system?

172 Posts

January 22nd, 2010 07:00

It could be a charging system problem but, if you have the latest FW, where there have been some fixes on that area, it should not.

You can power on the system and let the battery charge when the system is on.  With a PERC 5 you will need to reboot in order to see if the battery has charged, PERC 5 just look for the battery at boot and it never check back on it.  With PERC 6, power up, and when the battery is good to use, the controller will pick it up. 

30 min or 1 hr should be enough for the battery to charge, if the battery is still good.  There is a possibility your battery is bad and it does not hold the charge, you will need a new one.

Also make sure you have the latest system BIOS.  The BIOS is responsible for checking on the battery and show the E1211 error on the small LED panel on the front of the system.

 

 

 

 

4 Posts

November 17th, 2010 06:00

I just replaced with a new battery purchased from Dell.  It has charged for 20+ hours and I am still having the problem.  I have PERC 5/i Integrated 5.0.1-0030.  What is my next step?  I'm a software guy, not a hardware guy so any even apparently minor details would be appreciated.

7 Technologist

 • 

16.3K Posts

November 17th, 2010 09:00

The battery is only part of the grander system that could affect its status.  The battery is connected to the riser card, and the battery's charge/state is managed by the controller.  So, if you are having battery charge issues, it could be the riser card (either the battery connector/circuitry) or the controller that is at fault.

First, make sure your BIOS, ESM/BMC, and RAID firmware (drivers first) are up to date.  That will ensure that the hardware is operating at its most efficient.  If it still doesn't charge, you should look at replacing the riser first, then the controller.

If you have any questions - post details specific to your machine and problem, as no two problems are just alike.

39 Posts

October 24th, 2011 08:00

Okay, but what is the difference with 'Firmware' vs. 'Driver?' I have Perc 5/i and when I download the latest from Dell, I get the package that places Firmware 5.2.2-0072 (latest, greatest), but NO DRIVER! The driver still shows out of date, with Min required version 2.24.00.32 (current version being 2.13.00.32). Also, when I look on my other 2950's, the Storport driver, I think, is 6.1, whereas the below shows I also have older 6.0 Storport driver.

Firmware/Driver Information for Controller PERC 5/i Integrated  

Caution

Driver version is out of date.

Firmware Version 5.2.2-0072

Driver Version 2.13.00.32

Minimum Required Driver Version 2.24.00.32

Storport Driver Version 6.0.6002.18005

Apparently. Dell's package (RAID_FRMW_WIN_R189337-Perc5i-5.2.2.exe) contains ONLY the Perc 5/i "firmware" and not the updated "driver." [NOTE: I added the "Perc5i-5.2.2" part to the name, for easy description).

Any help greatly appreciated on finding the DRIVER vs. the FIRMWARE.

Regards,

J.

7 Technologist

 • 

16.3K Posts

October 24th, 2011 10:00

Correction on my original post ... the battery is not on the "riser" in a 2950 ... it is connected directly to the PERC but mounted to the chassis above the drives.

Firmware is code on a device telling it how to act, behave, and respond to certain requests and is independent of the OS.  Drivers are OS-specific code that tells the OS how to talk to a device.  No firmware update will contain a driver, as there would be too many combinations to be practical.

Best-practice calls for drivers to be updated before firmware, but here is the driver.  It is found in the same place as the firmware updates, just labeled "driver":

2008 x86:

2003 x86:

Did you already update the BIOS and ESM/BMC?  If not, you will need to update them too:

BIOS:

ESM/BMC:

 

 

39 Posts

October 28th, 2011 12:00

Actually, no, those are not the drivers that I need - but I do appreciate the information.

I should have been more specific: I need the 64-bit (2008 Server R2) drivers - and, as I said, they do NOT show up, when you go to Dell's site.

Thus, either there are no updated Perc 5/i 64-bit drivers yet, or...? Dell is not posting them? I think I also checked LSI site, but I'm a bit fuzzy right now.

So, if you go to Dell / Support and so forth, and choose 2950, 2008 Sever R2, you will see ONLY THE FIRMWARE and NOT the driver, for the Perc 5/i.

Conversely, if you choose 2008 x86 (i.e., 32-bit), then, yes, you will see the 32-bit drivers.

If you do find any 64-bit, please let me know.

Oh, and also thanks for the tip - "best practice says update the driver first."

Which begs the question - IF you update the firmware before the driver, and then later try to update the driver, will that cause any issues?

If so, what are the options & steps to "go back" to the old firmware, and then update to the newest driver, and then re-apply the firmware?

I ran into one issue personally, that seemed to tell me, "No, you can't do that, the software is not compatible with this driver" - or something along those lines.

That was with a Broadcom NIC where I already updated firmware, then came back, found newer driver from Broadcom, tried to apply, and "no go."

FYI, I have seen some notes saying things like: "Delete the device from device mgr, do 'find new hardware,' then point to the newer driver;

once that loads, then go back and re-apply latest firmware." Has anyone personally been able to do this?

Or (best practice aside) is it okay, in some cases, to update driver 'after' updating firmware?

Anyone had personal experience going back and updating drivers 'after' firmware already was updated?

Any help greatly appreciated!

39 Posts

October 28th, 2011 13:00

Thanks - that answers 99.9% of my issues.

I am doing "fresh installs" of 2008 R2, no upgrades or any of that.

The displayed driver that I gave you is exactly what shows up, so if it happens to be 32-bit driver on 2008R2, then I suppose that is what it is.

I am charting our 150 or so servers in an Excel sheet, so I can see exactly which version of BIOS, f/w, perc, bmc, etc. and compare those.

If there are no specific LSI Perc 5/i 2008 R2 drivers and it works fine with whatever "native" piece, then it's probably not a big deal, and maybe the OpenManage is simply seeing the ".32" as the last one that was known or... something?

I saw another brief note - maybe was a different Perc, but the person mentioned he was able to get the R2-compatible (or 64-bit functional) latest drivers for the Perc 5 by pulling down the Perc 6 pacakge - ?

And in yet another note, I saw that one person was able to make the 2003 x64 drivers work for 'another' 64-bit o/s, and it may have been Win 7 x64 that he was talking about.

Again - thanks - great info, as always!

7 Technologist

 • 

16.3K Posts

October 28th, 2011 13:00

2008 R2 is 64-bit only, so when you said your current version is 2.13.00.32 (32 meaning 32-bit), then I assumed you could not be working with 2008 R2.  That is reason for my supplying drivers for 2008 and 2003 32-bit.  There are 64-bit drivers for Server 2008x64 (non-R2) and 2003x64, but not for 2008 R2 (see below).

So, let's get sorted out which you are actually using, so we can head in the right direction :)

The 2008 R2 drivers are not listed because they are "native" (built-in) to Server 2008 R2.  Meaning that you do not have to load special drivers in order for Windows to see the drives.  You DO however have to configure RAID in CTRL-R BEFORE Windows will be able to see a disk to install to (the PERC's do not support non-RAID).

It CAN cause issues to update the firmware before the driver.  It is unusual, but possible (hence "best practices") ... and usually happens when the firmware and driver are very old.  New drivers can always speak to old firmware, but if the firmware changes radically (more common with jumping/skipping many updates on older devices than single updates), then the driver may not know how to talk to it with the new changes/requirements.  That said, with your existing installation, you would update the 32-bit driver to the latest, then update the firmware and you will be fine.  Then, if you are going to install 2008 R2, the firmware will already be at the current (and supported) level.  The update packages will not always tell you when you don't have the prereq's in place - and you shouldn't count on it.  If ever you do update the firmware first, you can usually simply update the driver and all will be fine.  If all seems well, you should be fine without reflashing the firmware.  Like I said, it is more common when making drastic changes to the firmware (say skipping 10 updates from the current to the latest without updating the driver first).

39 Posts

October 28th, 2011 13:00

OH, and the other thing that gets worrisome is when the OpenManage, while viewing the Storage section, says, "Warning, one or more storage drivers is out of date..." - along those lines. So, generally, to get rid of those, we update the drivers, but I will verify if these are showing such warnings. Thanks.

No Events found!

Top