Forum Discussion

Aspirant

Mar 14, 2019

Solved

Random shutdowns resulting in do_exit+4ac error on LED readout

My new ReadyNAS is repeatedly shutting down for an unknown reason. The LED readout on the front of the device displays "do_exit+4ac". Does anyone have advice on how to diagnose the root cause of this...

Hopchen

Mar 15, 2019

Hi LoftySnowman

Thanks for the logs. The good news is that your disks, raid and filesystem are fine. That is the most important.

I can see the boot issue happening and in fact I can see that the NAS ends up in a boot-loop from time to time. Seemingly, the NAS boots up but then immediately reboots itself.

Mar 13 18:16:43 readynasd[2068]: readynasd log started
Mar 13 18:16:44 readynasd[2068]: readynasd started. (restarted=0)
Mar 13 18:17:01 readynasd[2068]: Using fan mode: quiet
Mar 13 18:17:02 readynasd[2068]: ReadyNASOS background service started.
Mar 13 18:17:42 readynasd[2068]: The system is shutting down.
Mar 13 18:18:35 readynasd[2068]: Exit main thread by SIGTERM.
Mar 13 18:18:35 readynasd[2068]: readynasd is halted.
-- Reboot --
Mar 13 18:25:41 readynasd[2073]: readynasd log started
Mar 13 18:25:42 readynasd[2073]: readynasd started. (restarted=0)
Mar 13 18:25:59 readynasd[2073]: Using fan mode: quiet
Mar 13 18:26:01 readynasd[2073]: ReadyNASOS background service started.
Mar 13 18:26:21 readynasd[2073]: The system is shutting down.
Mar 13 18:26:39 readynasd[2073]: Exit main thread by SIGTERM.
Mar 13 18:26:39 readynasd[2073]: readynasd is halted.
-- Reboot --
Mar 13 18:27:48 readynasd[2073]: readynasd log started
Mar 13 18:27:49 readynasd[2073]: readynasd started. (restarted=0)
Mar 13 18:28:07 readynasd[2073]: Using fan mode: quiet
Mar 13 18:28:09 readynasd[2073]: ReadyNASOS background service started.
Mar 13 18:28:22 readynasd[2073]: The system is shutting down.
Mar 13 18:28:45 readynasd[2073]: Exit main thread by SIGTERM.
Mar 13 18:28:45 readynasd[2073]: readynasd is halted.
-- Reboot --

I dove into the kernel logs and found a successful boot sequence and a boot sequence where the NAS fails (and then reboots). I compared those and they are mainly the same except for the end of boot. Here is an extract of the end of a successful boot. It ends with the NIC going up and ready.

kernel: eth [al_eth_1]: set link speed to 1000Mbps. full duplex.
kernel: al_eth 0000:00:03.0 eth1: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

Here is the end of a failed boot and we can see that the NIC does come up not correctly.

kernel: al_eth 0000:00:03.0 eth1: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
kernel: configured MAC to RGMII mode:
kernel: al_eth 0000:00:03.0 eth1: using MSI-X per Queue interrupt mode
kernel: libphy: al mdio bus: probed
kernel: al_eth 0000:00:03.0 eth1: phy[5]: device 18:05, driver Atheros 8035 ethernet
kernel: al_eth 0000:00:03.0 eth1: phy[5]:supported 2ef adv 2ef
kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
kernel: eth [al_eth_1]: set link speed to 1000Mbps. full duplex.
kernel: al_eth 0000:00:03.0 eth1: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
kernel: al_eth 0000:00:03.0 eth1: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
kernel: al_eth 0000:00:01.0 eth0: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
systemd-shutdown[1]: Sending SIGTERM to remaining processes...
-- Reboot --

To me, this looks like either a hardware issue or the NIC driver possibly getting "wedged". So, either an issue with the chassis or an issue with the OS software. There are things you can do to diagnose this further but if you are still under hardware warranty, I would raise a ticket with NETGEAR and let them see if the chassis is faulty.

Are you still under HW warranty?

Cheers

LoftySnowman

Aspirant

Mar 15, 2019

I appreciate it. Note that I made I typo in an earlier reply. I am running the 6.9.5 firmware.

Hopchen

Prodigy

Mar 15, 2019

Hi LoftySnowman

Thanks for the logs. The good news is that your disks, raid and filesystem are fine. That is the most important.

I can see the boot issue happening and in fact I can see that the NAS ends up in a boot-loop from time to time. Seemingly, the NAS boots up but then immediately reboots itself.

Mar 13 18:16:43 readynasd[2068]: readynasd log started
Mar 13 18:16:44 readynasd[2068]: readynasd started. (restarted=0)
Mar 13 18:17:01 readynasd[2068]: Using fan mode: quiet
Mar 13 18:17:02 readynasd[2068]: ReadyNASOS background service started.
Mar 13 18:17:42 readynasd[2068]: The system is shutting down.
Mar 13 18:18:35 readynasd[2068]: Exit main thread by SIGTERM.
Mar 13 18:18:35 readynasd[2068]: readynasd is halted.
-- Reboot --
Mar 13 18:25:41 readynasd[2073]: readynasd log started
Mar 13 18:25:42 readynasd[2073]: readynasd started. (restarted=0)
Mar 13 18:25:59 readynasd[2073]: Using fan mode: quiet
Mar 13 18:26:01 readynasd[2073]: ReadyNASOS background service started.
Mar 13 18:26:21 readynasd[2073]: The system is shutting down.
Mar 13 18:26:39 readynasd[2073]: Exit main thread by SIGTERM.
Mar 13 18:26:39 readynasd[2073]: readynasd is halted.
-- Reboot --
Mar 13 18:27:48 readynasd[2073]: readynasd log started
Mar 13 18:27:49 readynasd[2073]: readynasd started. (restarted=0)
Mar 13 18:28:07 readynasd[2073]: Using fan mode: quiet
Mar 13 18:28:09 readynasd[2073]: ReadyNASOS background service started.
Mar 13 18:28:22 readynasd[2073]: The system is shutting down.
Mar 13 18:28:45 readynasd[2073]: Exit main thread by SIGTERM.
Mar 13 18:28:45 readynasd[2073]: readynasd is halted.
-- Reboot --

kernel: eth [al_eth_1]: set link speed to 1000Mbps. full duplex.
kernel: al_eth 0000:00:03.0 eth1: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready

Here is the end of a failed boot and we can see that the NIC does come up not correctly.

kernel: al_eth 0000:00:03.0 eth1: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
kernel: configured MAC to RGMII mode:
kernel: al_eth 0000:00:03.0 eth1: using MSI-X per Queue interrupt mode
kernel: libphy: al mdio bus: probed
kernel: al_eth 0000:00:03.0 eth1: phy[5]: device 18:05, driver Atheros 8035 ethernet
kernel: al_eth 0000:00:03.0 eth1: phy[5]:supported 2ef adv 2ef
kernel: IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
kernel: eth [al_eth_1]: set link speed to 1000Mbps. full duplex.
kernel: al_eth 0000:00:03.0 eth1: Link is Up - 1Gbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
kernel: al_eth 0000:00:03.0 eth1: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
kernel: al_eth 0000:00:01.0 eth0: al_eth_down
kernel: [eth rx] warn: dma state didn't change to Disable
kernel: [eth rx] warn: failed to change state, error -110
systemd-shutdown[1]: Sending SIGTERM to remaining processes...
-- Reboot --

Are you still under HW warranty?

Cheers

StephenB
Guru - Experienced User
Mar 15, 2019
Hopchen wrote:

but if you are still under hardware warranty, I would raise a ticket with NETGEAR and let them see if the chassis is faulty.

I agree, though I'd start by requesting an RMA. They will check it out. You can request the RMA at my.netgear.com.

Note that most RN214 should still be under warranty, as it was released in October 2015 (and has a three year warranty for the original purchaser). But if you purchased early, then don't delay.
LoftySnowman
Aspirant
Mar 15, 2019
If I did an RMA and popped the disks into a new unit, would it wipe the disks? I have been trying the second ethernet port and haven't yet seen another shutdown. I did purchase this NAS in the middle of February, so it should still be under warranty.
Hopchen
Prodigy
Mar 15, 2019
Hey again

The data and the OS and all the settings are stored on the disks. You can simply move the disks into a new unit and power it up.

https://kb.netgear.com/22895/ReadyNAS-OS-6-Migrating-a-volume

To migrate a volume to a diskless ReadyNAS OS 6 system:

Gracefully shut down the new (diskless) storage system.

Remove each disk in the volume from the old system.

Install each disk in the volume into the new storage system.

Turn on the new system by pressing the Power button.

Of course, always make sure you have backups sorted before doing anything :)
LoftySnowman
Aspirant
Apr 06, 2019
Thanks for your help diagnosing the issue. I did switch over to the second ethernet port. The ReadyNAS stopped shutting down for a while. After a couple weeks, the random shutdowns started again. This time I upgraded the firmware to 6.10.0 and the shutdowns got worse. With your suggestion I did work with customer support and am opening an RMA for the unit. I will likely use it as a non-primary device from now on, given how quickly the first one failed and how difficult it was pulling my data off of it onto a backup.
Sandshark
Sensei - Experienced User
Apr 06, 2019
The NIC uses +5VSB (5 volt standby) power in order to support WoL. That's a separately regulated bus within the NAS for just the NIC and power on/off circuitry, and yours sounds like it is failing, as that will cause both random shut-downs/power cycles and failure to boot properly when it does.. It's not repairable (at least by the user), so I hope you are under warranty. It is unlikely the external supply is at fault, but you could try another if you have one. It's not even enough of a chance that it would work that I recommend you buy one to try.

The +5VSB stays on all the time, even when the NAS is "off". If your NAS has an opportunity to get hot when it's "off", that can stress the +5VSB regulator to the point of failure.

There is a chance there is just a build-up of dust, pet hair, etc. (especially in a smoking household where the smoke residue serves as "glue") that's causing the regulator to overheat. If you aren't in warranty, opening the case and blowing out any dust could help, though perhaps not for long if the regulator is already overstressed. Note: Don't let the fan spin really fast from blowing out the dust. Use something to hold it stationary. Over-revving the fan is bad for the bearings.