[Pro Pioneer 6.5.1] NAS becomes unresponsive after random interval

---

MaxxMark wrote:

no thats not true. 6.6 appeared in my web-admin at the time. Had to close it manually everytime I entered the webadmin. I didn't want to update it as long as the backup of the NAS wasn't complete. 

 

 

---

That is correct.  The legacy NAS should be see these updates when they query the update server - assuming Netgear hasn't changed that policy or accidentally broken the query for legacy.

---

MaxxMark wrote:

 

I read that the 7.7.0 never made it to the web-admin because it was retracted before it got there. That lead me to believe that there is a period of time where the update could still be retracted. 

 

---

You mean 6.7.0.  It was released for manual install, but then Netgear decided to retract it (before it reached the update server).  They deleted from their servers so manual downloads no longer worked.

Some of us had done the manual install (including me).  I had no problems with 6.7.0, so I just kept it running until 6.7.1 was released.

Yes, i meant 6.7.0. Typo :)

Just for ease of mind (and partially, lazyness) I'm still gonna wait untill it hits the update server :)

6.7.1, Uptime 8 and half day, working perfect, no crash (with 6.6.1, i had crash every day, sometimes 2 per day)

I've tried updating 6.7.1, and additionally I performed a BIOS update on the board hoping that would fix it. No dice.

Same exact hang less than 24 hours after updating to 6.7.1.

From journalctl: 

May 15 11:41:37 blackbox kernel: eth1: hw csum failure
May 15 11:41:37 blackbox kernel: CPU: 1 PID: 0 Comm: swapper/1 Tainted: P      D W  O    4.4.62.x86_64.1 #1
May 15 11:41:37 blackbox kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080014  07/26/2010
May 15 11:41:37 blackbox kernel:  0000000000000000 ffff88014fc83c78 ffffffff883cf3c8 ffff88014b3b1000
May 15 11:41:37 blackbox kernel:  ffff880083ef3601 ffff88014fc83c90 ffffffff88908095 ffff88011fd95700
May 15 11:41:37 blackbox kernel:  ffff88014fc83cc0 ffffffff888fd263 31cbce344b3b1078 ffff88011fd95700
May 15 11:41:37 blackbox kernel: Call Trace:
May 15 11:41:37 blackbox kernel:  <IRQ>  [<ffffffff883cf3c8>] dump_stack+0x4d/0x65
May 15 11:41:37 blackbox kernel:  [<ffffffff88908095>] netdev_rx_csum_fault+0x35/0x40
May 15 11:41:37 blackbox kernel:  [<ffffffff888fd263>] __skb_checksum_complete+0xc3/0xd0
May 15 11:41:37 blackbox kernel:  [<ffffffff8896ef9f>] icmp_rcv+0x1cf/0x370
May 15 11:41:37 blackbox kernel:  [<ffffffff8893b60f>] ip_local_deliver_finish+0x8f/0x1e0
May 15 11:41:37 blackbox kernel:  [<ffffffff8893bbb2>] ip_local_deliver+0x42/0xd0
May 15 11:41:37 blackbox kernel:  [<ffffffff8893b580>] ? inet_del_offload+0x40/0x40
May 15 11:41:37 blackbox kernel:  [<ffffffff8893b854>] ip_rcv_finish+0xf4/0x2c0
May 15 11:41:37 blackbox kernel:  [<ffffffff8893be67>] ip_rcv+0x227/0x380
May 15 11:41:37 blackbox kernel:  [<ffffffff88097303>] ? enqueue_task_fair+0x93/0x850
May 15 11:41:37 blackbox kernel:  [<ffffffff88090aaf>] ? sched_clock_cpu+0x7f/0xa0
May 15 11:41:37 blackbox kernel:  [<ffffffff88905de9>] __netif_receive_skb_core+0x409/0x760
May 15 11:41:37 blackbox kernel:  [<ffffffff8808b64f>] ? check_preempt_curr+0x4f/0x90
May 15 11:41:37 blackbox kernel:  [<ffffffff88908131>] __netif_receive_skb+0x11/0x70
May 15 11:41:37 blackbox kernel:  [<ffffffff889097d1>] process_backlog+0x91/0x120
May 15 11:41:37 blackbox kernel:  [<ffffffff8890961f>] net_rx_action+0x1af/0x2d0
May 15 11:41:37 blackbox kernel:  [<ffffffff8806e97f>] __do_softirq+0xef/0x1f0
May 15 11:41:37 blackbox kernel:  [<ffffffff8806eb90>] irq_exit+0x70/0x90
May 15 11:41:37 blackbox kernel:  [<ffffffff8802c31e>] smp_call_function_single_interrupt+0x2e/0x30
May 15 11:41:37 blackbox kernel:  [<ffffffff88a4c74f>] call_function_single_interrupt+0x7f/0x90
May 15 11:41:37 blackbox kernel:  <EOI>  [<ffffffff8800b916>] ? mwait_idle+0x66/0xa0
May 15 11:41:37 blackbox kernel:  [<ffffffff8800be0a>] arch_cpu_idle+0xa/0x10
May 15 11:41:37 blackbox kernel:  [<ffffffff8809f91e>] default_idle_call+0x2e/0x40
May 15 11:41:37 blackbox kernel:  [<ffffffff8809fac2>] cpu_startup_entry+0x192/0x270
May 15 11:41:37 blackbox kernel:  [<ffffffff8802c8de>] start_secondary+0xfe/0x120

Every time, same deal. I wish I could confirm this was a hardware failure and just throw the thing in the trash already. But it was rock-solid until literally a day after I updated it from I believe 6.2.4 to whatever the next version was. Ever since then, same problem. I used to have uptimes of hundreds of days with this thing, and since that update it hasn't lasted more than 72 hours without a crash.

As an update;

After my update to 6.6.1 (27-04-2017) I only had one restart, which was a manual reboot because there was a network issue (unrelated to the unresponsiveness).

Right now it has been up voor 14 days again. It _seems_ that the problem went away (or at least it is much less frequent). But I'll only celebrate when it hits a 30+ day uptime again.

I also haven't had any crashes since my previous post a month ago. The system is running 6.6.1 as before, and nothing else has changed. The only thing I can think of is that there is less backup/synching being done now than before.

I too have had this exact same issue rear it's ugly head on numerous occassions with my ReadyNAS Pro 6 NAS since upgrading to OS 6.x (currently on 6.8.0 and it's still occuring).

Anyone ever find a solution to this? It's frustrating to say the least.

Pro6: I have crashes too, just lost 16TB data last month, (RAID5 gone after a crash...)

My Ultra6 still working after last restart, 17day.

Up until recently, I had 4 ProBE/Pro6 models running 6.x and had only one crash I can recall over an 18 month period.  Two ran continuously and the other two came on nightly for backup.  I did have 2GB of RAM in the backup systems and 4GB in the active ones, which may have made a difference.

Oh, interesting. I've just ordered a 2 x 2GB RAM kit, so I'll see how it performs with the additional RAM. It's currently loaded with the stock 1GB. Fingers crossed.

2 x 2GB sticks arrived. Installed them last night, and all good for 21 hours and then... unresponsive. Hard restart required.

Bummer. 

Anyone had any more luck with this?

---

monochromic wrote:

 

Anyone had any more luck with this?

---

My pro-6 isn't running OS-6, but I do have 2x4GB memory installed.  The NAS can be quite fussy about memory, and I've never owned a Pro Pioneer.  But if you post the specifics on what memory you ordered, then some other folks might be able to give you more help. 

FWIW, you might want to double-check that both chips are fully seated.

I have Ultra6 and Pro6 too.

With 6.8.0, Ultra6 is stable, (now 26 days, 22 hours, 20 minutes, last restart was because of change the UPS battery, not crash)

Pro6 crashing after 1-3 day. (E7500 CPU, 2x1GB DDR2-800 RAM). And I found, the chipset (big silver heatsink) is very-very hot. Moreless untouchable. I have 2pcs 40x40x20  COOLTEK CT-SILENT FAN4020 on this heatsink, directly powered from molex,and still 70-75 celsius.

CPU temp is normal, I use a powerfull Alpenföhn Silvretta cooler on it.

When I used under ReadyOS 4.2.31, it was colder. Not just the sensor temp show it, I felt it to with my finger. Maybe 20-25 celsius colder.

Maybe the chipset controll have problems in the OS6? And affected on Core2 and Pentium based stuff only, but not the Atom maybe.

---

MaxxMark wrote:

As an update;

 

After my update to 6.6.1 (27-04-2017) I only had one restart, which was a manual reboot because there was a network issue (unrelated to the unresponsiveness).

 

Right now it has been up voor 14 days again. It _seems_ that the problem went away (or at least it is much less frequent). But I'll only celebrate when it hits a 30+ day uptime again.

---

Just to reply on myself; 

It's almost 5 months later, and after upgrading to 6.6.1, the problems seemed have gone away. I had continued to run 6.6.1 for a while and hadn't had any problems since. I had done a full factory reset last month (went from raid-6 to raid-5, which was unrelated to the problem though).

In my situation the upgrade to 6.6.1 resolved the issue. But based on other threads, it doesn't feel like it explicitly fixed an issue. Ive seen new updates which helped others, but didnt help mine. And I expect that this version fixed mine, but probably doesn't fix issues for others.

Can you share you configuration? The exact type, part number of your cpu and memory modules?

Now I ordered E2160 CPU and 1gb DDR2-667 ram module from ebay, this is the original config of my NAS (now I use with E7500 and 2x1GB DDR2-800 ram).

I will reply, if I got the stuffs and installed and tested for a month.

I don't thnk that's it.  I have E7400's in mine, and don't have that issue.  Having only 1GB of RAM might be a bigger problem, as all native OS6.x machines have 2GB.

I've upgraded both the RAM and the CPU in my Pro 6 quite some time ago, before 6.x was even available. My NAS was completely stable on 6.x until after one of the point version upgrades. I don't remember exactly, but I think 6.2-something was the last time it worked 100%.

Everything I've been able to find about this issue points to an ethernet driver problem. It's either that or I have failing hardware, but that seems highly unlikely.

cpu and mem is 7USD togethet (with post), I can try it.

I tried testing with disc-change.

Primary setup: 2x4TB WD_Red + 4x3TB WD_Red, all in a Raid5/X-RAID. All disc 100% health, no bad sector or any other error

Secondary setup: 6x500GB mixed drive (WD Blue, WD Green, Seagate Barracuda,Toshiba, Hitachi, Samsung), all in a Raid5/X-RAID. 3 disc health 100%, other 3 have bad sectors, Samsung is only 22% in HDSentinel.

With the Secondary setup, my NAS worked 15day without error.

than I changed to Primary this morning.

Now 21:59, 6crash today.

I tested all of discs in primary, with WD Diagnostic, with HD sentinel, no error.

Incompatible HDD maybe?

Oh, I forgot:

Tested with 1x1GB DDR2-666 mem: Crash

Tested with 2x1GB DDR2-666 mem: Crash 

Tested with 1x1GB DDR2-800 mem: Crash

Tested with 2x1GB DDR2-800 mem: Crash

Tested with E2130 CPU: Crash

Tested with E5800 CPU: Crash

Tested with E7500 CPU: Crash

Maybe the NAS is faulty. But for everybody???

New test:

I apply memory just for the left side slot (CPU side, not front side).

After 1 day, no crash yet.

As best I have been able to tell, the Pro RAM is not dual channel.  So other than having less, only using one slot should not affect performance.  Hope that fixes your problem.