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

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