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.
Keep saying that it is a problem of a few users is at least offensive. I had the same problem since upgrading to 6.2.2 and I wish all those who have the same problem would write an email to put an end to this farce.
I logged in with ssh to see if i can solve the problem and: 1) At one point "ls" seg faulted. Seriously. Never saw a thing like this. Retyped "ls" and worked flawlessly 2) At one point "ps aux" failed. "Signal 11 (SEGV) caught by ps (procps-ng version 3.3.3). ps:display.c:59: please report this bug". Unbelievable. 3) "cat /etc/passwd" and there are some directories that do not exists 4) The kernel is the incredibly old Linux 3.0.101.RN_ARM.3 5) At some point a process named "fvbackup-q" start taking 100% of CPU time. In the time i take to google what that process even "top" failed: "signal 4 (ILL) was caught by top, please report..."
This is not a simple bug, the all packaged system is a mess (wrong compiler version?, wrong c library?) So please stop writing offensive marketing messages and start working at it seriously.
Fulvio I can assure you that we are doing all we can to resolve this as soon as possible.
Can you please send in your logs too?
3) which directories don't exist? Home shares for users are created on the first login using SMB (you need to logout and login again before they appear). On systems with e.g. 100s or 1000s of users (e.g. imported from Active Directory) creating home shares automatically without a user even logging in is not practical. 4) This kernel has backported changes from newer kernels. The kernel in 6.2.x is basically the same as what we were using in 6.1.x. From the very first OS6 firmware 6.0.0 through to the latest 6.2.3 beta we have been using 3.0.x kernels. Reports that things were working fine on 6.1.x indicate thus indicate that the kernel is most likely not the problem. Having said that we have a newer longterm kernel 3.12.x in 6.3.x. There is an early access beta of this firmware for users with x86_64 models. We are working on bringing the new kernel to our ARM models such as the 102 and 104. 5) That is used for backup jobs. What backup jobs are you running? What protocol are you using for those? What are the full backup job settings?
However I installed the "stress" program (apt-get install stress) and launched with: stress --cpu 8 --io 4 --vm 2 --vm-bytes 256MB &
to see if the problem may be caused by some hardware failure. The answer is no, but the interesting part is that i was finally able to copy all the data with a SMB connection (without the stress running in background the RN102 always freezed).
I don't know if it's because stress prevents some power save mode, or because the network traffic is slower, but I hope it helps to find a solution.
***EDIT*** Just running in background: stress --cpu 8
As per any company people need to speak with their wallets. I have noticed the 2 main suppliers I use have been offering money off the RN104 for the last 2 months especially. Nearly every 2nd email I get off dabs is flogging off the unit. I tried to leave my review pointing to these forums and for people to have a good read before even thinking about buying the unit. 7 days later my review has not been published and dabs are not replying.
My review is negative due to nearly 2 years of problems that have accumulated in a small black hard drive holder sitting on my desk. Review your system, point to here, explain your views but try to convey them without frustration.
We are continuing to look into why lockups are occurring for a number of users and attempting to reproduce this problem. It is as frustrating for us as it is for you that the issue has not been reproducible. When an issue cannot be reproduced it can add considerable time especially when the cause of the problem is not showing in the logs.
What reviews a reseller chooses to publish is up to them. On the forums we value the openness of users to give their opinions both positive and negative. It's one one of the things I love about community forums.
What reviews a reseller chooses to publish is up to them. On the forums we value the openness of users to give their opinions both positive and negative. It's one one of the things I love about community forums.
Indeed, my point is to in future look at forums like this for your products. there was 1 review out when I bought my RN104. Sites like dabs will try to put up positive reviews as they want to sell units. Would you imagine people are looking at OS6 and the RN line atm and thinking they will purchase one. But if people review honestly and even update their reviews even the people who don't check forums might be saved making mistakes.
i have noticed the the system use the "armadaxp_idle" driver for cpuidle (http://www.landley.net/kdocs/ols/2007/ols2007v2-pages-119-126.pdf)
Since the system do not lock when "stress" is running, and since support for the armada 370 is very new (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c3c7fe7ce0d8a3ef55ebb88f3b24e074735845dd) and the kernel used is the old 3.0 kernel: there is a way to disable cpuidle at runtime? Can you provide a beta with a kernel compiled without cpuidle?
***EDIT*** Just running in background: stress --cpu 8
is enough to make the system stable.
I was curious about this and gave it a try but alas it did not solve my problem. I ended up with a core-dump like one of my recent posts but this time it was stress that died. The strange thing is that pretty much the whole system is broke after that. webui, smbd, you name it. the only thing that still worked after the crash was my current ssh-connection and the top I had running. When I tried to reboot it froze up and needed a power-cycle as usual.
It was a "Internal error: Oops: 17 [#1]" , will post a more complete dump when I reproduce the error.
About to throw this black thing out the Window, can't rely on it at all. Will try 6.2.0 again as it stayed on longer with that firmware before locking up
About to throw this black thing out the Window, can't rely on it at all. Will try 6.2.0 again as it stayed on longer with that firmware before locking up
This ain't a fix and it won't solve the lockup problem, but at least you won't have to pull the power cord from the rn104, every time it lockups:
Access the rn104 through ssh and edit etc/sysctl.conf file. Place the following two lines in the end:
kernel.panic = 1 kernel.panic_on_oops = 1
Save and reboot.
What this will do is to restart the rn104 just before a lockup and since the reboot takes just a few minutes, it's a way to get along until there's a real fix.
What this will do is to restart the rn104 just before a lockup and since the reboot takes just a few minutes, it's a way to get along until there's a real fix.
It is worth noting that kernel panics can cause data loss: when saving some changes to a file the kernel can cache the data => the kernel fails before flushing the cache and automatically reboots => the user thinks that everything is ok but in reality lost the changes...
I have been running fine with my readynas for over a year. I updated the firmware to 6.2 and now it locks up regularly. An unacceptable attribute in a piece of hardware that you are entrusting with your backups of your most valuable data. I spoke with custmer service and they informed me that I must pay to have them help repair the damage that the new firmware caused. I was not willing to pay. I paid the local PC supply house to buy a new external HDD. I backed up everything on my ReadyNAS and restored and reformatted the system and then copied my data back on. It is still failing. When will netgear realize that they have released a faulty firmware and it is destroying the credibility of their products. I need to rely on this machine. Should I revert to 6.1.9? Is that even possible? This is a trainwreck. Of course, if you talk to netgear customer service, it is my fault and therefore i must pay them. Should we not install any firmware updates after the support period has ended? Is that the message I am to receive? I am very dissapointed and would like a fix to this flaw immediately. I have already wasted much of my valuable time and money on this mistake made by Netgears software engineers
I have been running fine with my readynas for over a year. I updated the firmware to 6.2 and now it locks up regularly. An unacceptable attribute in a piece of hardware that you are entrusting with your backups of your most valuable data. I spoke with custmer service and they informed me that I must pay to have them help repair the damage that the new firmware caused. I was not willing to pay. I paid the local PC supply house to buy a new external HDD. I backed up everything on my ReadyNAS and restored and reformatted the system and then copied my data back on. It is still failing. When will netgear realize that they have released a faulty firmware and it is destroying the credibility of their products. I need to rely on this machine. Should I revert to 6.1.9? Is that even possible? This is a trainwreck. Of course, if you talk to netgear customer service, it is my fault and therefore i must pay them. Should we not install any firmware updates after the support period has ended? Is that the message I am to receive? I am very dissapointed and would like a fix to this flaw immediately. I have already wasted much of my valuable time and money on this mistake made by Netgears software engineers
We have a saying for what we are going through trying to get accountability for this issue and this NAS. It is called pissing against the wind. Your comment will be replied to with some of the follwing copy and paste:
"We were still unable to reproduce the problem" "This is happening to some users" "the 90 day support is a norm in the tech industry."
IMO, your lucky to have had 12 months with a working NAS. I am currently 22 months trrying to get this to work as advertised.
Not installing any firmware updates would be bad as you could run into issues fixed by firmware updates you decided not to install. Most of the time you can downgrade if you don't like a new firmware. We do warn in the Release Notes where this is not possible. In any case if your data is important to you, no matter where you store it, store it on multiple devices.
As I mentioned earlier though we have the 90 day support warranty we have still decided to work with a few users from this thread on diagnosing the problem obtaining crash dumps. We are do everything we can to resolve this problem as soon as possible.
At least it is the number one thread with significantly higher activity than any of the others. I am hoping they are at least aware that there is a real problem affecting most users. How many less tech-savvy business owners have just given up and purchased a competitors product assuming the readyNAS just got old and died? Th 8200 people who have viewed this already are just a small population of the consumers affected. This is a real problem Netgear; don't bury your head in the sand! Your NAS market reputation is being destroyed day-by-day. Maybe this is a statement of your/their business intentions and consumer response forthcoming.
We know it is a real problem and this problem is getting attention from the highest levels of our team. We want to resolve this as soon as possible but as discussed the difficulty in reproducing the problem has meant this issue has remained open for much longer than all of us would like.
Note that each time I view the thread for example it increments that counter of the views. I reckon at least 100 (maybe a lot more) of the views are probably from me alone. So a high view count indicates a mixture of repeat viewing of threads and a number of users viewing it.
At this stage I would consider this issue is affecting many users but not most (if it was affecting most it would be easily reproducible), but what is important and what I think we all agree on is that this problem needs to be solved as soon as possible.
I am an owner of a fledging Readynas Duo V2, several years old now. This is reminiscant of the many months of threads containing user frustrations in regards to latency / MTU issues with Windows OS's. An adequate solution was never forthcoming.
My Readynas Duo is now on its last legs, locking up and dropping off the Network for no apparant reason, however from my investigations I suspect it is also Kernal panic introduced by one of the later firmware upgrades. Third to last release, to be exact (at work at the moment, dont recall the Version).
I love the readynas hardware and the user interface, but unfortunately it is let down yet again by buggy firmware.
I was ready to go out and purchase a new RN31200, but have to say this current situation scares me off no end.
