FWIW I updated from 6.2.4 to 6.4.1 and had a few minor issues:
1. wordpress was no longer working. I hadn't used it much so I uninstalled for now, but if I had been a big wordpress user I might have been pissed.
2. My external USB drives got renumbered and this whacked all my backup jobs. The backup UI would not let me change the destination locations even though it said "no longer exists". So I found the mount config files (storage.conf and usb_map). I made the edits to restore the names to the drives (apparently the identifiers for the seagate externals is different than what it was on 6.2.4. The mybook I have attach preserved it's name.) Rebooted and the drives are back with the right names.
CPU is 1622 and system fan is 907. CPU is 37c and system is 64c. This is no change for me. I think the cpu cooler is overdue for a cleaning. The system temp has always been high even though I can't feel it anywhere near that hot at any point inside or out. So far so good.
I upgraded my Pro6 from 6.4.0 to 6.4.1 and DVBLink TV Server stopped recognising the tuner. No doubt DVBlogic will update their driver in a new build, but just a word of caution for any others before upgrading.
This morning I found the system was hung. No access to anything including ssh. Log shows it was a GPF. The crash happened 10 minutes after a quarterly drive rebalance job I had scheduled. I power cycled and it came back up.
steve
Dec 03 04:25:31 warehouse6 kernel: general protection fault: 0000 [#1] SMP Dec 03 04:25:31 warehouse6 kernel: Modules linked in: nv6lcd(O) vpd(PO) Dec 03 04:25:31 warehouse6 kernel: CPU: 1 PID: 14484 Comm: sleep Tainted: P O 4.1.13.x86_64.1 #1 Dec 03 04:25:31 warehouse6 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 Dec 03 04:25:31 warehouse6 kernel: task: ffff88024686a010 ti: ffff8801cc78c000 task.ti: ffff8801cc78c000 Dec 03 04:25:31 warehouse6 kernel: RIP: 0010:[<ffffffff8811f337>] [<ffffffff8811f337>] filp_close+0x17/0x80 Dec 03 04:25:31 warehouse6 kernel: RSP: 0018:ffff8801cc78fef8 EFLAGS: 00010282 Dec 03 04:25:31 warehouse6 kernel: RAX: ffff8801091c8940 RBX: 8f5c21baea331f00 RCX: ffff88002c0cf000 Dec 03 04:25:31 warehouse6 kernel: RDX: 0000000000000001 RSI: ffff880246f7a5c0 RDI: 8f5c21baea331f00 Dec 03 04:25:31 warehouse6 kernel: RBP: ffff8801cc78ff18 R08: 00007fbe2e7727a0 R09: 00007fbe2e98c700 Dec 03 04:25:31 warehouse6 kernel: R10: 00007fffc6c08620 R11: 0000000000000246 R12: 0000000000000001 Dec 03 04:25:31 warehouse6 kernel: R13: 00007fbe2e771c60 R14: 0000000000000000 R15: 0000000000000000 Dec 03 04:25:31 warehouse6 kernel: FS: 00007fbe2e98c700(0000) GS:ffff88024fc80000(0000) knlGS:0000000000000000 Dec 03 04:25:31 warehouse6 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Dec 03 04:25:31 warehouse6 kernel: CR2: 00007fbe2e43fd20 CR3: 0000000173f0b000 CR4: 00000000000406e0 Dec 03 04:25:31 warehouse6 kernel: Stack: Dec 03 04:25:31 warehouse6 kernel: ffff8801cc78ff58 ffff880246f7a5c0 0000000000000001 00007fbe2e771c60 Dec 03 04:25:31 warehouse6 kernel: ffff8801cc78ff38 ffffffff8813d9ef 00007fbe2e7712a0 0000000000000000 Dec 03 04:25:31 warehouse6 kernel: ffff8801cc78ff48 ffffffff8811f2ee 0000000000000000 ffffffff889b2017 Dec 03 04:25:31 warehouse6 kernel: Call Trace: Dec 03 04:25:31 warehouse6 kernel: [<ffffffff8813d9ef>] __close_fd+0x6f/0x90 Dec 03 04:25:31 warehouse6 kernel: [<ffffffff8811f2ee>] SyS_close+0x1e/0x50 Dec 03 04:25:31 warehouse6 kernel: [<ffffffff889b2017>] system_call_fastpath+0x12/0x6a
Since upgrading to 6.4.1 my nas seems to lose all connectivity every couple of days. Only way out is to hard reboot. After the last reboot a couple of days ago, I noticed that it has started balancing - and again lost all connectivity (no web admin, no ssh, no ping reply etc). The balancing is also taking quite some time (it is at 12% after about 24 hours). There is about 800Gb free on a Raid 5 set up (5 x 2Tb on ReadyNAS PRo), so hopefully sufficient free space for the balancing.
Balancing is what preceeded the backtrace I posted. Could be a coincidence, but either way this is a kernel/driver bug. Applications cannot GPF/hang the OS like this. Netgear needs to get to the bottom of it.
If you have ssh access and are comfortable doing it use "journalctl -a" and find the time window prior to your rebooting to see if there was a kernel error that locked up the system.
I'm not seeing anything untoward in the journal logs before the hard reboots. Just various syncthing and dropbox related messages but nothing that is related to the NAS/file system specifically (both syncthing and dropbox have been working fine on the previous 6.2.x firmware).
Running 6.4.1 here on my Pro6 6 as well. I'm also seeing periodic crashes. Before I upgraded this box was rock-solid. I believe I was running 6.2.4, possibly 6.3.5. I upgraded to 6.4.0 and it started crashing every couple days, whereas previously I had over a hundred days of uptime before the upgrade.
I upgraded the unit to 6.4.1, still hangs every couple days. Just checked, there's a GPF showing up for me too right before the last crash. Doesn't look like it has anything to do with a balancing job though.
From journalctl:
Dec 06 22:20:09 blackbox kernel: general protection fault: 0000 [#3] SMP
Dec 06 22:20:09 blackbox kernel: Modules linked in: nv6lcd(O) vpd(PO)
Dec 06 22:20:09 blackbox kernel: CPU: 0 PID: 2183 Comm: connmand Tainted: P D O 4.1.13.x86_64.1 #1
Dec 06 22:20:09 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 10/03/2008
Dec 06 22:20:09 blackbox kernel: task: ffff8800a84e47d0 ti: ffff880147b5c000 task.ti: ffff880147b5c000
Dec 06 22:20:09 blackbox kernel: RIP: 0010:[<ffffffff88134784>] [<ffffffff88134784>] poll_freewait+0x64/0xb0
Dec 06 22:20:09 blackbox kernel: RSP: 0018:ffff880147b5fac8 EFLAGS: 00010206
Dec 06 22:20:09 blackbox kernel: RAX: 0000000000000282 RBX: 1f88d68fea331ec0 RCX: dead000000200200
Dec 06 22:20:09 blackbox kernel: RDX: dead000000100100 RSI: 0000000000000282 RDI: ffff880146df8700
Dec 06 22:20:09 blackbox kernel: RBP: ffff880147b5fae8 R08: ffff8800825c5200 R09: 0000000000000000
Dec 06 22:20:09 blackbox kernel: R10: 0000000000000000 R11: 0000000000000000 R12: ffff880033d2b010
Dec 06 22:20:09 blackbox kernel: R13: ffff880033d2b000 R14: ffff880147b5fc68 R15: 0000000000000000
Dec 06 22:20:09 blackbox kernel: FS: 00007fa1f217e700(0000) GS:ffff88014fc00000(0000) knlGS:0000000000000000
Dec 06 22:20:09 blackbox kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Dec 06 22:20:09 blackbox kernel: CR2: 00007fda6023fdf0 CR3: 0000000147b15000 CR4: 00000000000006f0
Dec 06 22:20:09 blackbox kernel: Stack:
Dec 06 22:20:09 blackbox kernel: ffff880147b5fbec 0000000000000000 0000000000000000 ffff880147b5fbec
Dec 06 22:20:09 blackbox kernel: ffff880147b5ff08 ffffffff88135b79 ffff8800ab9e7400 ffff8800825c5200
Dec 06 22:20:09 blackbox kernel: ffff8800825c5200 ffff880147b60000 ffff8800a84e47d0 0000000000292ef7
Dec 06 22:20:09 blackbox kernel: Call Trace:
Dec 06 22:20:09 blackbox kernel: [<ffffffff88135b79>] do_sys_poll+0x3e9/0x5a0
Dec 06 22:20:09 blackbox kernel: [<ffffffff888de7b0>] ? ip_forward_options+0x1f0/0x1f0
Dec 06 22:20:09 blackbox kernel: [<ffffffff888e0b44>] ? ip_local_out_sk+0x34/0x40
Dec 06 22:20:09 blackbox kernel: [<ffffffff888e1ea5>] ? ip_send_skb+0x15/0x50
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff881346b0>] ? __pollwait+0xf0/0xf0
Dec 06 22:20:09 blackbox kernel: [<ffffffff88135dfd>] SyS_poll+0x6d/0x100
Dec 06 22:20:09 blackbox kernel: [<ffffffff889b2017>] system_call_fastpath+0x12/0x6a
Dec 06 22:20:09 blackbox systemd[1]: connman.service: main process exited, code=killed, status=11
Dec 06 22:20:09 blackbox systemd[1]: Unit connman.service entered failed state.
Dec 06 22:20:09 blackbox systemd[1]: connman.service holdoff time over, scheduling restart.
Dec 06 22:20:10 blackbox readynasd[2376]: PropertyChanged (/ethernet_001f33ea8fd6_cable): State=configuration
Dec 06 22:20:10 blackbox raidard[2206]: got 1 interfaces:
Dec 06 22:20:10 blackbox raidard[2206]: IP=10.0.1.11 Mac=00:1f:33:ea:8f:d6 BroadAddress=10.0.1.255
Dec 06 22:20:10 blackbox readynasd[2376]: PropertyChanged (/): State=ready
Dec 06 22:20:11 blackbox readynasd[2376]: Service ethernet_001f33ea8fd6_cable changed
Dec 06 22:20:12 blackbox leafp2p[2196]: Restore server connection
Dec 06 22:20:16 blackbox leafp2p[2196]: Active notification manager
This is getting seriously annoying to the point where I'm ready to factory default and downgrade back to 6.2.4 if that's even possible. This used to be an amazing device, but a server that hard-freezes every couple days in a remote location is deal-breaker for me. This really sucks.
Anyone know if a downgrade to 6.2.4 or 6.3.5 is possible, assuming a backup and factory default?
Had a number of crashes over the last few days. Logs seem to show the same GPF errors as others have had. Before the upgrade to 6.4.1, the box was very stable. It does seem as if there is definitely a problem with 6.4.1.
So I finally had it with 6.4.1. I borrowed a 6 TB HDD from work, backed up all my data and downgraded back to 6.2.4, which required doing a factory default.
I've got everything reconfigured now and it's actually better than I had it previously. I haven't had a really long stretch of uptime since I got it redone because I've been screwing around with my network and changing things lately, but it's been consistently on with various reboots for about 3 weeks and I haven't had another crash.
Current uptime right now is about 7 days. On 6.4.1 I wasn't getting much past 4 days at the most before it'd hang.
So far so good. 6.2.4 is solid and 6.4.x provides nothing I want or need in terms of features. I see no reason to upgrade again in the forseeable future.
Just to echo concerns in this thread, I've had a lot of connectivity issues, system hangs, and general protection faults with 6.4.1, 6.4.2 RC1, and now 6.4.2. Happens every 2-3 days, whereas on 6.2.4 I was rock-solid with no problems for months.
Seeing this on an Ultra 6 Plus and my Pro Pioneer. Very odd behavior. The GPFs I'm seeing reference the nv6lcd and vpd modules. Got frustrated enough to do a factory reset and go back to a fresh 6.4.2 install. Worked fine for a few days and now back to the same behavior. There's definitely a gremlin in the 6.4.x release for those of use with legacy hardware, and maybe even for those with the newer OS 6 hardware if some of the other posts I've seen are to be believed.
At this point I'm considering factory resetting and following that procedure to go back to 6.2.4 again. The data's already all backed up from the last factory reset, so I might as well retreat to something more stable I guess. I've been contemplating upgrading to new hardware (a 516 or even 716), but the stability issues I'm seeing with OS 6.4.x is making wonder if it's worth it at this point.
Just to update this thread, I rolled my Pro Pioneer back from 6.4.2 to 6.2.4 after several weeks of kernel dumps from the LCD module. Things are nice and stable again on 6.2.4, up and running for 2 weeks straight with no issues.
