ReadyNas 6.2 (NAS locks up entirely)

Ok, so I made other test today. This time I tried to go back to basics by pulling all three of my WD Greens leaving a single drive in the bay. Reinstalled OS and went through the wizard as per usual. This time x-raid2 mode and JBOD since only 1 disk. Created a share and started to copy some files onto it. Somewhere about 30min to an hour of uptime if froze same as before.

Going to see how it behaves with the 3 wd greens in a default setup.

mdgm wrote:
The nature of these lockups appears to be quite specific to your environments. Otherwise we would have been able to reproduce them. We are continuing to look into it.

Why don't you guys put out a patch that allows us to go back to a clean install of 6.1.x...which is known to work in all of our "environments"?

Why don't you request someone to send you a clean install of 6.2.2 that locks up? Maybe you could send them one of your units that doesn't lock up?

Can you provide a specification of what you consider a "working" environment so we can create a similar "clean room" environment to test our units? I have two 104's suffering from this issue that I have transferred all the data off of into other systems and that have simply been reset to factory default that still lock up and I don't plan to use them until this is fixed, so I would be happy to create and perform a clean room test to your spec.

bobkellyrd wrote:
Why don't you guys put out a patch that allows us to go back to a clean install of 6.1.x...which is known to work in all of our "environments"?

I have already answered that and given a list of reasons. That's not a solution. Development of 6.1.x ceased close to half a year ago. You would be re-exposing yourself to problems fixed in 6.2.x, lose security fixes and other enhancements.

bobkellyrd wrote:
Why don't you request someone to send you a clean install of 6.2.2 that locks up? Maybe you could send them one of your units that doesn't lock up?

If it was that simple we would have tried that. If we did that we would likely find that your unit does not lockup in our environment and ours locks up in yours.

bobkellyrd wrote:

Can you provide a specification of what you consider a "working" environment so we can create a similar "clean room" environment to test our units? I have two 104's suffering from this issue that I have transferred all the data off of into other systems and that have simply been reset to factory default that still lock up and I don't plan to use them until this is fixed, so I would be happy to create and perform a clean room test to your spec.

The environment consists of everything on the network: the NAS, router, switch, modem (including the internet connection), your PCs, smartphones, tablets and any other devices connected to your network.

We need to know why it is locking up consistently in some environments and yet running better than ever in other environments with no lockups. This is why we are doing this:

mdgm wrote:
Netgear are working with 2 people who posted in this thread in relation to 100 series and random lock ups. There is nothing apparent seen in the logs so we are collecting info via serial connector.

My ReadyNas 104 has gone from being rock solid (never crashed) on 6.1.x to crashing multiple times a day after going to 6.2.x.

I have no apps installed and just use it share files on my network - I have 2 x 3Tb Seagate and 1 x 3TB WD Green drives in JBOD mode. (don't blame the drives as the problem is related to the firmware)

It is much more unstable on 6.2.2 crashing every few hours whereas it can go overnight on the 6.2.0 firmware, the 6.2.3 Beta was also very unstable. I've disabled all the snapshots (although one drive keeps saying that snapshots are still present), disabled DNLA and no spin down

Netgear need to give us the ability to rollback to 6.1.9 or come up with a fixed firmware - I don't particularly care about the reduced security, updates etc I just want my NAS to work normally again.

redhotchilli wrote:
or come up with a fixed firmware

That is what we are working on, but when a problem cannot be reproduced this takes time.

Can you send me your logs (see the Sending Logs link in my sig)?

Good morning.

Another day and another test, well did the test last night my time but managed to get some info this morning before I tried to enable ssh but it became unresponsive.

I Installed my 3 WD green disks, 1 x 3tb and 2 x 2tb and did a facory reset, after going through the setup-wizard I could confirm that the 104 was resyncing a raid-5 array of the disks with an est. time of 20-25 hours. Since it appeared to keep itself alive this time I went to bed. When I checked it this morning it still stood at 1.27% so I Went in and downloaded the logs and a quick check revealed this little gem. Then as I wrote above it looked up and seems to be in a unresponsive but alive state. Ping works, splashscreen after the login works but nothing further and the sshd did not start.

[Thu Feb 12 02:06:02 2015] Unable to handle kernel NULL pointer dereference at virtual address 00000050
[Thu Feb 12 02:06:02 2015] pgd = c0004000
[Thu Feb 12 02:06:52 2015] *pgd=00000000
[Thu Feb 12 02:06:02 2015] Internal error: Oops: 17 [#1]
[Thu Feb 12 02:06:02 2015] Modules linked in: vpd(P)
[Thu Feb 12 02:06:02 2015] CPU: 0    Tainted: P              (3.0.101.RN_ARM.3 #1)
[Thu Feb 12 02:06:02 2015] PC is at dev_check_rdonly+0xc/0x28
[Thu Feb 12 02:06:02 2015] LR is at list_sort+0x98/0x2a4
[Thu Feb 12 02:06:02 2015] pc : [<c038e9e0>]    lr : [<c03b1dc0>]    psr: 80000013
[Thu Feb 12 02:06:02 2015] sp : c791bde0  ip : c791bde0  fp : c791bddc
[Thu Feb 12 02:06:02 2015] r10: 00000003  r9 : 0000000c  r8 : c038e988
[Thu Feb 12 02:06:02 2015] r7 : 00000000  r6 : d9822000  r5 : d1094740  r4 : d9822bc8
[Thu Feb 12 02:06:02 2015] r3 : 00000000  r2 : 038539c0  r1 : 00000000  r0 : 00000000
[Thu Feb 12 02:06:02 2015] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[Thu Feb 12 02:06:02 2015] Control: 10c5387d  Table: 03f2c019  DAC: 00000015
[Thu Feb 12 02:06:02 2015] Process md127_raid5 (pid: 1429, stack limit = 0xc791a2e8)
[Thu Feb 12 02:06:02 2015] Stack: (0xc791bde0 to 0xc791c000)
[Thu Feb 12 02:06:02 2015] bde0: c791be8c c791bdf0 c03b1dc0 c038e994 c003203c c791be90 d9822cb0 00000003

From my update thread here:
http://www.readynas.com/forum/viewtopic.php?f=65&t=79916

chrizfitz wrote:

My latest advice is to rule out the disks with seatools and run the memory test boot option. I'm going to be doing this over the next 48 hours. the thing I find really funny is that I seem to be beta testing an officially released firmware. Is there a magic number of units that have to go through this? Would anybody honestly recommend the OS6 netgear devices? In my experience OS6 has never delivered in nearly 2 years of use. I can say that it hadn't from the start because the features advertised when I bought it like spindown were still to be added in later firmwares. And we all know how these updates are going. The excuse of not being able to replicate the issue surely cannot be enough. If a 3 disk setup in x-raid and plugged into a bog standard ISP router is a issue the device should not be sold. If you are selling a NAS designed for home use Joe Soap needs to be able to use it.

We have recently done extra testing of the 100 series to attempt to see if it could be reproduced in a typical home environment. We were still unable to reproduce the problem. Our testing found the NAS ran fine with zero lockups.

We don't release firmware without it passing QA testing.

Since we cannot reproduce it, it must be a problem that is specific to some environments. That is why we are using serial access to a few units with the problem to try to get the information we need to determine what is going on.

There are a huge number of environments out there in different places all around the world. It's unfortunate that problems like this one can happen and it's frustrating that the reason for the lockups aren't being logged.

It's inevitable that users with problems do most of the posting on the forums. We have seen a higher than usual level of posts about lockups which does show there is a problem, but still the majority of our users' systems are running fine.

We are doing everything we can to diagnose and fix the problem as soon as possible.

Look like Netgear is in the denial stage on this 6.2.x firmware. Home network is the simplest of all networks and this 104 NAS was aim at home use so anyone should be able to use it (as stated by chrixfitz).

mdgm, I appriciate that you are trying your best to help, but please do not question/undermind users in this forum on their network and computer knowledge.

I still insist Netgear should come to term and provide users a way to revert back to 6.1.x firmware.

Every home network is different. There are a huge number of things to consider as I mentioned earlier.

Router
Modem (including internet connection)
The NAS
PCs including OS and any software on it that interacts with the NAS.
Any other devices on your network

The fact this problem is only showing up in some networks does not discount that this is a real problem. It is a problem but it is not a universal one. If it was easy to reproduce in any environment we would have reproduced it.

Development of 6.1.x ceased months ago and the focus now is on 6.2.x and 6.3.x. Downgrading to firmware that is missing months worth of fixes and enhancements is not a solution. Also there are one way upgrades when upgrading to 6.2.x such as upgrades to the snapshots. We made it very clear in the release notes that once you have upgraded to 6.2.x you cannot go back.

The solution we are working on is to diagnose why the lockups are occurring and to fix those problems. We are doing everything we can to diagnose the problem and then address it as quickly as possible.

Now we don't know how many different causes there are for the lockups described in this thread that have not yet been fixed. It's likely that most are caused by one or two problems, but as the reason for the lockups are not being written to disk we can only speculate on that at this time. We can never assume that two problems that may have similar symptoms must be the same.

Some users who have had lockups on 6.2.2 have found they have already been addressed by fixes made in 6.2.3 Beta. Others have not.

Clearly many users in this thread have lockups that cannot be explained by disk issues. Lockups can occur due to bad disks, bad memory etc. As every case is different we cannot discount the possibility that some users may be having problems caused by disk issues. That is a reason why I have been asking for logs from a number of users.