NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS 104 upgraded to OS 6.4.0 shutdown hang
Following upgrade to this release I am unable to shutdown. System hangs with "Shutting dow. Goodbye." - I left it in this state overnight. Power must be removed to complete shutdown.
Can confirm beta 3 fixes the no shoutown with custom MTU issue.
Thanks. No, I had the same problem upgrading 6.2.5 to 6.4.0 where it would not upgrade until I hard factory reset the box using a paperclip.
I will try a hard reset and see if that works. I had no problem upgrading 6.1.9 to 6.2.4 and then 6.2.5... But 6.4.0 has presented problems.
I will try a hard reset and see if that works. I had no problem upgrading 6.1.9 to 6.2.4 and then 6.2.5... But 6.4.0 has presented problems.
An update: An update to 6.4.1. beta 3 won't work on my rn102. Back with Netgear support to investigate the problem. Looks like I have the "mismatched checksum" issue with upgrading 6.4.0 to 6.4.1 beta 3. This is the same issue I had with 6.2.5 to 6.4.0 upgrade.
The issue manifests where the uploaded, update image file checksum does not match the expected checksum. On a reboot, the system tries to flash the image, notices the checksum of the file does not match what is expected, and promptly does not flash the image update to the system. The error is silent and does not show in the OS6 log file. The admin webpage silently remains on the previous version.
The previous workaround was to install an "app" which netgear created. The "app" addressed "the known issue".
To discover if this is an issue, the initrd log file (when you "download logs" from the log page of frontview) shows something like:
[2015/11/16 19:27:49] Update image checksum mismatch (f5c6610f8a13b136600a1481017e7a4e/1b743406f16f4c33e8a121f72da05702)!
Netgear support have "escalated this to R&D"
Beta 3 installed on my RN102 using a modified workaround from the 6.2.5 -> 6.4.0 update: Installed the Beta 3 update, DID NOT RESTART and installed the workaround update file. On restarting I was on 6.4.1-T35 (Yay!)
Enabled Jumbo Frames, and restarted = OK
Started copying files to the NAS = slightly slower that MTU 1500 - why? DMESG and kernel logs show heaps of:
mvneta d0074000.ethernet eth0: bad rx status 0f830000 (overrun error), size=xxx
where xxx is a frame size less than 9000
Anyway, shutdown NAS from OS6 ..... AND..... same problem as before. The NAS is still on, with blue lights lit, but no response. Pulling power is the only way to shut it down.
Beta 3 has not solved my MTU 9000 problem. Back at MTU 1500 the box is CPU limited on transfers but shuts down and wakes-on-LAN. Back with NG support.
I have had the same issue twice and I still have not changed the MTU value from the original setup of 1500.
Why is supposed it happens only wit big MTU numbers?
OK. Shutdown hang is now fixed for me in Beta 3. The box DOES shutdown gracefully with any MTU. BUT
New problem - Jumbo frames with wake-on-LAN ON leads to an instant, unprompted, unrequested wake-up...
Confirmed by netgear support as an issue and escalated to engineers/R&D - workaround is to use MTU 1500 with Wake-on-LAN on. It appears there is limited internal testing on theses betas. Aren't you supposed to fix bugs and then regression check fixes and changes against existing functionality?
The buffer overrun issue remains and impacts on data transfer performance - either CPU limited at MTU 1500 (with buffer overrun) or increased buffer overruns on MTU 9000 with broken wake-on-LAN - both impact functionality and performance.
We'll wait for the new version. RC1 released, but doesn't contain fix.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
