Pascal,
I looked at the code that handles the reset button press. It is handled in the mts-io kernel module and by the reset-monitor process. The kernel module keeps track of a short press (~5s), a long press (> ~5s && < = ~30s), and an extra long press (> ~30s).
On AEP, for a short press a SIGHUP is sent to the reset-monitor. For a long press a SIGUSR1 is sent to the rest-monitor. For an extra long press a SIGUSR2 is sent to the reset monitor. These are not the hard-coded defaults, but are set on boot by the AEP watchdog process. On the AEP Conduit the reset monitor process is the watchdog process. The following is what happens for each button press length:
short press (< ~5s): the system just reboots
long press (> ~5s && < ~30s): the device is reset to user defined defaults and rebooted. The factory settings are used if user defined defaults have not been set.
extra long press (> ~30s): the device is reset to factory defaults.
I believe that the status LED should go solid at the start of reboot until the kernel is back up and the mts-io module is reloaded, then the status LED should start blinking normally again, but don’t quote me on that as I have not dug into that functionality to verify that.
I have not observed any behavior outside these parameters on my device, however it is only one device, and the hardware is almost a year old.
I am interested what the load is on these devices that are exhibiting this bad behavior on reset. If you have time to gather some information and let me know here or file a support portal ticket at https://support.multitech.com, please let me know. If you can provide the following information:
1) Output of a top command to see what the CPU and memory state of the system is.
2) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor.
3) A ‘cat’ of /sys/devices/platform/mts-io/reset-monitor-intervals
That would be a start to figure some of these issues out. If #’s 1, 2, and 3 look OK, maybe it is an actual bad hardware problem.
Jeff