NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
ReadyNAS Pro 4 Kernel Panic
Hi guys,
I've got a ReadyNAS Pro 4 that seems to be kernel panicking on occasion (usually every few days). The LCD will display "_raw_spin_lock_bh+16" when this occurs and I have to perform a hard reset.
The NAS has been upgraded to ReadyNAS OS 6 (currently running 6.9.4) and I've increased the RAM from 1GB to 2GB (the maximum that the chassis supports according to dmidecode).
The NAS is purely an iSCSI Target, storing backup data (so there's only one VM accessing it). It's configured in RAID-5 and has 4x 1TB 7.2K SATA disks in it. The volume is encrypted, if that makes a difference.
Hi guys,
Sorry it's a few months down the track now but I thought I better do the right thing and come back in case anyone else experiences this. It looks like with the combination of heavy I/O from the maintenance tasks coupled with heavy I/O on the backup LUN stored on it (there are regular backups every 3 hours) was starving the RAID volume of IOPS and effectively crashing the OS because it couldn't write to it's disks quickly enough. The balance appears to have just been the symptom of that problem.
Unfortunately I can't say anything for certain, but I SSH'd into the NAS and watched it under load and the CPU was really struggling and the load averages were really high. I've adjusted my backup schedules to try and avoid heavy writes during the hours the NAS could potentially be doing maintenance and it hasn't crashed since.
6 Replies
Replies have been turned off for this discussion
Hi dojobel, if there is only one vm accessing the nas, I would not investigate much about the error and how to overcome it, but would do the following:
1) Wake up the nas using WOL (wake on lan). You need to allow the wake up on the nas side and on the vm execute a batch containing
...path...\wol.exe <macaddress_of_nas> and a command making the vm wait for a certain amount of time until the nas is up and can be accessed.
2) Use the vm to shutdown the nas following the example in
https://community.netgear.com/t5/ReadyNAS-Storage-Apps-Old-Legacy/WOL-amp-Shutdown/m-p/827132
Of course, that is not a (true) solution, but I would call it a very practical workaround.
Kind regards
Retired_Member wrote:
Hi dojobel, if there is only one vm accessing the nas, I would not investigate much about the error and how to overcome it, but would do the following:
1) Wake up the nas using WOL (wake on lan). You need to allow the wake up on the nas side and on the vm execute a batch containing
...path...\wol.exe <macaddress_of_nas> and a command making the vm wait for a certain amount of time until the nas is up and can be accessed.
2) Use the vm to shutdown the nas following the example in
https://community.netgear.com/t5/ReadyNAS-Storage-Apps-Old-Legacy/WOL-amp-Shutdown/m-p/827132
Hi mate, thanks for your input! Unfortunately the VM needs 24x7 access to the NAS, so even though it's a single VM, uptime is still very important for this NAS. The VM is driving my backups which run every few hours during the day, then overnight the NAS has some idle time so it can run scheduled maintenance tasks and such.
I originally thought this problem was due to a lack of RAM, however it has been occurring since the upgrade. I checked the logs after the last crash and noticed a BTRFS Balance task had been started just prior to the crash. I have a ReadyNAS Pro 6 doing the exact same thing, coincidentally:
The only common ground between the two is they are running iSCSI, I'm utilising MPIO and there are 2x Hyper-V hosts that attach to these LUNs.
FYI I've started a balance task to see if I can replicate the crash, will report back.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
