NanD failure on WD MyBookLive?

Hardware Questions and Recommendations
1

My 8 year old WD MyBookLive is starting to slow down and I've got it to gather the logs and I've noticed this one message which is showing up more and more. Any idea what this means?

MyBookLive kernel: ndfc 4fff80000.ndfc: failed to get memory

I have tons of those errors in the Kern.log file.
I've looked up ndfc and that came back as NanD Flash Controller. So, that unit has 256MB of RAM on it, is that starting to fail at that one address?
The OS is Debian 5.0 and Linux says it has a PowerPC chip in it. Yes, the WD MyBookLive OS is way out of date, but it works... so far.
Is there way that I can test the RAM in it? Can OpenWRT help me diagnose the device and will OpenWRT allow me to use memtest to check the RAM?

2

I do not think there is any diagnostics that you can run on OpenWrt that isn't also available on Debian.

1 Like
3

I was hoping since Debian 5 is so outdated and the repositories are gone, that OpenWRT could offer me more packages which might include a RAM diagnostic tool since it's more maintained.

4

That doesn't look like a RAM problem to me. Faulty ram causes random crashes, not something like this. Unless u-boot or the kernel already identified the faulty RAM, and is running with less actual RAM now. If you have shell access, you can look at the amount of available ram with command 'free' .

If a nand-daemon is complaining about not getting memory, I'd suspect the nand. Maybe that address is unreadable flash, or due to flash problems the daemon has a big backlog of stuff which has to be written to flash, and can't allocate enough RAM to store that.

1 Like
5 
MyBookLive:~# free -m
             total       used       free     shared    buffers     cached
Mem:           247        236         10          0         28         75
-/+ buffers/cache:        133        114
Swap:          488         28        460

247 MB? What happened to the 256 MB? Hmm...
Since I am using the stock firmware, it should all work. I guess the -9 MB less RAM is making the system throw those errors? Also, would it cause these slowdowns that I am seeing if the system is trying to access that address that has been marked as bad?

6

This seems correct (maybe slightly small). Not sure how Debian calculates.

So, this isn't OpenWrt related?

Also, I don't see anything indicating the issue you note (i.e. RAM failure)...further, 'ndfc' relates to the non-volatile flash anyways.

7

I was just wondering if OpenWRT would offer me more tools than the default stock firmware. If it did, I would install it on to the MBL.
Non-volatile flash? Would that be on the main board of the MyBook Live or hard drive?

8

That's on the main board. It's a chip. Probably nand,

2 Likes
9

Thanks! Time to start looking for sales, then?

10

It's been quite some time since I last used MBLs with their stock firmware, but I remember that they always ran notoriously low on RAM - 20 MB or less free RAM was usual. A lot of this is cached, I am assuming by the Samba server, but there's a reason why WD have decided to include and use a swap partition. So, no, I don't think that's your issue.

Also, yes, I witnessed MBLs getting slower over time. I have no idea what is degrading and why, and I wouldn't want to guess, but I can confirm the problem. My MBLs started out at ... I want to say 80, 90 MB/s, and in the end after a good 6 or 7 years of use, they maybe did a third of that at best? Again, it's been some time.

The tiny NAND chip is only 512 kb and only holds the bootloader. I have never seen an MBL's NAND fail, it is only used for a second at boot after all. But it's entirely possible that yours is failing, I have seen MBLs fail in weird ways. MBLs are going into their teenage years now, after all.

Anyhoo, this being the OpenWrt forum, I can, from own experience, recommend running OpenWrt on an MBL. It runs leaner (about 200 MB RAM free after boot), almost as fast as stock, and way more "standard" than the highly customized Debian of the stock firmware. And obviously it's a completely current system, not one that is almost a decade old.

However, it's not as "plug and play" as the stock firmware, not even close. You will have to get familiar with setting up the base system and every single service you want to run on it. And even though a lot of it is written up and this forum is usually quite helpful, don't expect much handholding. And then there's the issue that you can not "convert" a drive, you will need to transfer all your data to another disk first because the disk will need to be reformatted. The wiki page (which, full disclosure, I wrote a major chunk of) is a start if you're interested.

1 Like
11

So, if that's the bootloader, I guess it would take longer to start up?
At least the DC plug hasn't melted down, I saw that on the WD Community forum.
As for the heavy RAM use, yes I see that. 10 MB of free space! Yikes!
I hope with it's current state that it's in that it would last me a few more years.
With this COVID situation, I'm putting the DLNA server to good use and none of my workout videos have experienced any playback issues. Also, no connection issues .... yet. Windows will tell me that it sometimes can't find \MYBOOKLIVE (age?) It will let me transfer large files over without any issues.

12

No, either it works or it doesn't. Loading and starting the bootloader itself only accounts for a fraction of a second, the rest is loading and booting the system, and that happens from the hard drive.

Not necessarily. I believe a lot of it is cached RAM, and that would be no different under OpenWrt. If you run top from the command line, you will have the RAM usage broken down further. "cached" means that Linux is using free RAM to cache file system data. In a way, it is RAM that is not currently used by anything important, but if it's there, Linux doesn't let it go to waste and uses it for less important things.

I hope so too. If you can live with a bit slower operation, it should still serve you just fine. When in doubt, never change a running system™, if it's not broken don't fix it™, et al etc. pp.

13

This is after a full factory restore of the MBL.
image