What's new

FYI: AM 386.12 on AC86u - how to decrease # of random reboots

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

bibikalka

Regular Contributor
I was trying to fix random reboots on my AC86U with AM 386.12_4 that is running AiProtection and other proprietary features. Even daily auto-reboots would not help - the router could crash-reboot even after an hour or two in operation. Also, lots of issues like this were discussed in the official release thread by @RMerlin by others.

Recently, I came across this simple fix here (full credit to @ColinTaylor !):

The RT-AC86U has a known problem with nvram access. It is described in this thread. The issue is exacerbated by running certain custom add-on scripts that make frequent nvram calls.
The issue can be reduced to some extent by adding the following line to the beginning of the /jffs/scripts/init-start script.
Code:
#!/bin/sh
echo 4194304 > /proc/sys/kernel/pid_max

This fix really seems to help. Now in 1 week I had just 1 random crash, whereas before I'd have 7-10. I still get lots of "unhandled level 3 translation fault (11)" from dcd/asd - but they don't seem to cause as much trouble anymore.

I do keep auto-reboots in /jffs/scripts/post-mount, since they don't disrupt anything and take place when nobody is doing any activity:
Code:
cru a ScheduledReboot "5 4 * * * /sbin/service 'reboot'"

Anyway, if you are on AC86U - try this and report back. More details on the issue in this stuck thread here . If the improvement is across the board - it could be worth adding to the next official release for AC86U.
 
I was trying to fix random reboots on my AC86U with AM 386.12_4 that is running AiProtection and other proprietary features. Even daily auto-reboots would not help - the router could crash-reboot even after an hour or two in operation. Also, lots of issues like this were discussed in the official release thread by @RMerlin by others.

Recently, I came across this simple fix here (full credit to @ColinTaylor !):



This fix really seems to help. Now in 1 week I had just 1 random crash, whereas before I'd have 7-10. I still get lots of "unhandled level 3 translation fault (11)" from dcd/asd - but they don't seem to cause as much trouble anymore.

I do keep auto-reboots in /jffs/scripts/post-mount, since they don't disrupt anything and take place when nobody is doing any activity:
Code:
cru a ScheduledReboot "5 4 * * * /sbin/service 'reboot'"

Anyway, if you are on AC86U - try this and report back. More details on the issue in this stuck thread here . If the improvement is across the board - it could be worth adding to the next official release for AC86U.

@bibikalka... if I were you, I'd just turn off AiProtection altogether. That thing caused me so much grief. Even when I was on my old AC86U, I never really suffered from random reboots... it was more stuck scripts that would hang things up. But turning that off might help with your reboots. Try disabling as much unneeded stuff on your router as possible, like AiProtection... do you need adaptive QoS... traffic analyzer... etc. Turn off all the things... keep it simple. Less chances of something causing a fatal error.

One wonderful utility that came out of all this was @Martinski's CheckStuckProcCmds.sh script... works great for the AC86U, and run it on a regular basis... like every hour! It will "unstuck" those stuck proc/NVRAM commands...


 
@bibikalka... if I were you, I'd just turn off AiProtection altogether... Try disabling as much unneeded stuff on your router as possible, like AiProtection... do you need adaptive QoS... traffic analyzer... etc. Turn off all the things...

One wonderful utility that came out of all this was @Martinski's CheckStuckProcCmds.sh script... works great for the AC86U, and run it on a regular basis... like every hour! It will "unstuck" those stuck proc/NVRAM commands...



Yep, I'd turn off AiP stuff, but cannot - it's needed in the household for now. Lesser evil - otherwise I'd have to replicate similar functionality with more hassle for me :(

Proprietary code blobs are really poison since their bugs live forever - but sadly this is as good as it gets with Asus here.

I did try CheckStuckProcCmds.sh script, and on the 1st day it found stuck processes. But, since doing "echo 4194304 > /proc/sys/kernel/pid_max" the stuck script does not find anything at all! So big success I guess!
 
It's been a few weeks since I implemented pid_max increase. With daily reboots, I only observed stuck nvram commands right after nightly reboots, about once every 10 days. Otherwise nothing seems to get stuck during the normal router operation.

Code:
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:12:02 740560     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:11:46 788243     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:11:30 1175132     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:11:14 1176006     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:10:57 1304724     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:10:41 1304906     1 admin    S N   2972  0.7   1  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:10:24 1412506     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:10:08 1412773     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:09:52 1526357     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:09:35 1526993     1 admin    S N   2972  0.7   1  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:09:19 1645812     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:09:03 1646334     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:08:46 1754955     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:08:30 1755638     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:08:13 1870467     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:07:57 1874822     1 admin    S N   2972  0.7   1  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:07:41 1991589     1 admin    S     2972  0.7   1  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:07:24 1992143     1 admin    S N   2972  0.7   1  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:07:08 2107300     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:06:51 2108113     1 admin    S N   2972  0.7   0  0.0 nvram get custom_clientlist [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:06:35 2203757     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00007_2328773.TRC.txt:2024-02-09 04:06:18 2307458     1 admin    S     2972  0.7   0  0.0 nvram get vpn_server_custom [KILLED]
StuckProcCmds_00008_34886.TRC.txt:2024-02-13 04:30:19 32771 32710 admin    S     3104  0.7   0  0.0 nvram get buildno [KILLED]
StuckProcCmds_00009_35078.TRC.txt:2024-02-22 04:30:19 32771 32770 admin    S     3104  0.7   0  0.0 nvram show [KILLED]
 
Perhaps replacing the router is a better fix. Daily reboots to keep it going is not really a solution.

This router has more common issues on top including sudden death after blown voltage regulator.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top