D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DSN-2100 => Topic started by: NetworkSIN on March 23, 2011, 04:33:21 PM
-
Received this message this morning on a DSN-2100 with FW 2.8.0.48. Anyone have any insight? I have not rebooted yet. I am kinda fed-up with this unit as it does not seem stable enough for production (although I use it in production - not my choice, I am forced). I should not have to keep rebooting this thing every few months for it to act right. ??? And on top of all that, I set the smtp setting to email me when there is problems (i know it is configured right because the tests are successful) yet it does not email me on this problem although it clearly shows this as an error (not just a info message).
Category:
System
Severity:
Error
EventID:
General message
Source:
Startup
Summary:
module BM: The battery checker daemon failed
Sequence ID
35897
Text1
module BM: The battery checker daemon failed
I received the following on 03/19/11 and 03/21/11.
Category:
System
Severity:
Error
EventID:
General message
Source:
Startup
Summary:
module BM function battery_charger_daemon: Battery transition from charged to charging
Sequence ID
35872
Text1
module BM function battery_charger_daemon: Battery transition from charged to charging
-
And as I stated before. The only way to fix this battery failed error is to reboot the SAN. Now the battery is charged and maintains charge for about 3-5 months.
If the system has power, but the battery is failing, how does a simple reboot magically charge the battery? What a pain to have to shutdown multiple servers (especially if your doing clustered shared volumes) just to force the system to realize the battery is not dead.
The reason this is important is because when the battery fails, the system goes into write through mode , which is slow. When the battery is charged, the system goes into write back mode, which is much faster write speed.
Does anyone experience this or know of a resolve?
-
I'm having the same problem and it's quite annoying. We're running a number of machines on this SAN and we really cannot afford to bring them down.
Is there a way to access the system managing the SAN unit to restart the battery daemon? I imagine it's just an embedded Linux OS of sorts...
Justin
-
I should also add that event logs do not show *any* events after that battery daemon failed, however I am able to download the event history zip file (for what that's worth). >:(
Justin
-
Justin,
I opened up a ticket with Dlink last week. I pointed them to this forum thread as this is the first search item that pops up on google when searching. Hopefully, they can fix this issue and reply back to this thread with updated firmware or solution. It was pretty difficult to find anything on the net about this issue, let alone information from Dlink support.
-
Cross check items in the eventhistory.log with the term "Info" with corresponding events in the xstack gui history table. If you are seeing "EngInfo" events in the eventhistory.log but not in the xstack gui, that looks to be normal.
In comparing problems here, I can see events in the xstack gui as long as they are "Info" messages, but I do see where "EngInfo" messages do not appear in my xstack gui. Looks like "EngInfo" are not displayed on the actually gui but just the eventhistory.log file.
-
Thanks for letting me know.
I do hope that this issue is easily resolved. I will be rebooting the SAN this Thursday (4/7/2011) for other maintenance and hopefully I'll find out if the battery is indeed dead, or if the daemon itself died and thinks the battery is dead. This unit is 2 months old.
I also noticed that 4 of the 6 drive LEDs on the motherboard are showing up orange and not green however, there is no indication anywhere in the system of any faults. I don't know if that's an additional problem or not, but performance on this SAN has been miserable since day 1.
Best,
Justin
-
What firmware are you running?
-
I'm running 2.8.0.48
Justin
-
Thanks.
Dlink suggested (which is solely based on 1 internal ticket they received from an outside caller) that another user had a similar issue and the caller supposedly figured the issue was arising due to the server room being too hot. (sounds unlikely that this could be the issue here).
Also, another forum admin here suggested ( on another similar issue), to shut it down, take all the drives, battery, and memory out. Then let it boot as far as it will go. Replace everything.
Since it looks like, we are having to do the work for DLink :o , I think we should compare our scenarios.
My tests:
Room to hot: My server room is at constant 75 degrees.
Pull all parts and reboot: I have not done this yet. I do not even want to go down this route, as if it does work, it shows poor craftmanship on DLinks part. And I do not want to have to keep doing that every few months.
FYI, my unit is about 1 1/2 years old.
Firmware: 2.8.0.48
MFG Board Revision: 0D03
Nand Memory Size: 256mb
Buffer Size 2x1gb (2gb total)
Ssytem Memory Size: 512mb
-
My tests
Room too hot
This is certainly possible for me. The room isn't temperature controlled and it's between 80-86F. Currently 85F.
Pull all parts and reboot
I'm not going to try this, but I'm willing to try a reboot (which does make me nervous).
Firmware: 2.8.0.48
MFG Board Revision: 0D04 <- newer?
Nand Memory Size: 256mb
Buffer Size: (2x256mb): 512mb
Sytem Memory Size (2x256mb): 512mb
Best,
Justin
-
A reboot will be fine. To do it right, just make sure that there is no active iscsi connections to the volumes and reboot at will.
Order of rebooting:
1. terminate all iscsi connections. Can be done from client computers with the initiators.
2. check to see there are no active connections to iscsi targets.
3. reboot dlink san.
4. Check that battery is charging (if not still continue on to next step)
5. reconnect all iscsi initiators.
done.
-
Thanks! :)
Please let me know what support says regarding your ticket. What is the support number you called? I wasn't able to find one, so I just emailed their world-class email support address... ::)
Justin
-
Sure thing. I will post it in this thread for everyone to see.
:-)
-
I just spoke with support regarding my battery and I was told that they will in fact RMA the battery (I'm waiting for their call back). I'm rebooting my SAN tonight and I will report back if that resolves the issue or not.
Yay... ::)
Justin
-
An update on this scenario:
We rebooted the SAN and the battery checker daemon did not pick up the battery, so clearly it is defective.
I have put in a support call with D-Link and they will RMA the battery - that's good. HOWEVER, support is demanding that we send in the defective battery first, before they will send us a new battery - that's NOT good.
How can a company sell an SMB SAN product and expect their customers to bring the majority of their IT resources to remove an old battery and then have to bring it down *again* to install the new battery?
I've tried to contact my support representative
Chenda Keo
RMA Coordinator
D-Link Systems, Inc.
However, I have not heard from him in a few days. ???
What's the deal?
Justin
-
Another update:
D-Link agreed to send us the new battery so we do not need to bring down the SAN twice. I have received it this morning and will be installing it today. Hopefully this resolves the issue...
Justin
-
Just brought the business down, swapped the new battery in and same problem. Stuck in write-thru mode...
I'll be on the phone with support tomorrow! >:(
justin
-
The battery charged over night and the system is now in Write Back mode, as expected.
So it looks like, for anyone who runs into this problem in the future, you will most likely need to replace the system battery if you have this battery checker daemon problem.
Justin
-
I cannot fully agree with a simple battery change that is the issue here without elaborating a bit.
Likely causes:
1. The battery was defective from day 1 (seems like this is most likely).
2. The board circuitry going to the battery is defective (also seem likely).
3. The firmware is at fault. (with Dlink's track record with this particular SAN, this is also likely and what I believed the situation was all along, hence the reason I did not contact Dlink the first few times.)
If cannot simply be that if you get this error, that you need to replace the battery without stipulating that the need to replace the battery is because it was defective to begin with.
In my situation, Dlink has agreed with my assumptions above.
From Dlink Support:
Regarding the battery issue, we can see some events that indicate the battery could be successfully charged. There are two possible causes:
1. The battery has an intermittent problem, so sometimes it can charge correctly and other times it cannot be fully charged correctly.
2. The controller PCBA has an intermittent problem with the circuit that communicates with the battery
It is difficult to understand the exact cause based only on the information in the Event Log. As a temporary step, we recommend that you replace the battery and see if the problem is still existing after the replacement.
My Response to this is:
1. That is an observation, not a technical diagnosis.
2. This is possible, if so, DLink should step up and honor their 3 year warranty on defective parts!
-
Does this particular issue cause your system to crash when trying to make adjustments to volume sizes? I have the same Battery Daemon error but am having DLink investigate this issue. They have not gotten back with me on what the diagnostics is. Just wondering if any user had the unit crash during this error?
Thanks