What's new

ASUS RT-AC86U firmware release 3.0.0.4.384.45713

  • 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!

Had issues with this firmware. After making changes to the Tx Power Adjustment, the router became unresponsive, with both wifi and cable connection not working. Had the new firmware run for a day before the changes to monitor potential issues.

After hardware reset to factory, got back into the router. Performed reset to factory twice with minimal config. Router seemed to work fine and connected to the ISP except the WAN led was RED.

Code:
Apr 25 11:20:20 acsd: Adjusted channel spec: 0x1004 (4)
Apr 25 11:20:20 acsd: selected channel spec: 0x1004 (4)
Apr 25 11:35:21 acsd: selected channel spec: 0x1009 (9)
Apr 25 11:35:21 acsd: Adjusted channel spec: 0x1009 (9)
Apr 25 11:35:21 acsd: selected channel spec: 0x1009 (9)
Apr 25 11:50:24 acsd: selected channel spec: 0x100a (10)
Apr 25 11:50:24 acsd: Adjusted channel spec: 0x100a (10)
Apr 25 11:50:24 acsd: selected channel spec: 0x100a (10)
Apr 25 12:05:27 acsd: selected channel spec: 0x1001 (1)
Apr 25 12:05:27 acsd: Adjusted channel spec: 0x1001 (1)
Apr 25 12:05:27 acsd: selected channel spec: 0x1001 (1)
Apr 25 12:20:30 acsd: selected channel spec: 0x100b (11)
Apr 25 12:20:30 acsd: Adjusted channel spec: 0x100b (11)
Apr 25 12:20:30 acsd: selected channel spec: 0x100b (11)
Apr 25 12:35:32 acsd: selected channel spec: 0x100a (10)
Apr 25 12:35:32 acsd: Adjusted channel spec: 0x100a (10)
Apr 25 12:35:32 acsd: selected channel spec: 0x100a (10)
Apr 25 12:50:33 acsd: selected channel spec: 0x1003 (3)
Apr 25 12:50:33 acsd: Adjusted channel spec: 0x1003 (3)

This was on the wireless set to auto channel. System log was showing channels changing every few minutes. After a day, power reset the network and the WAN led was restored to the normal white. Plus the channel was not changing as frequently.

Seemed very weird behaviour with this firmware. This is with a router that had not shown any hiccups since installation for over a year now.
 
That's unfortunate ... can you post your logs? Did you do a full factory reset / nvram wipe etc?

Log for a dcd crash below & I have not done a full factory reset with 384.11 alpha4 flash.

Apr 25 12:51:53 kernel: dcd[8189]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Apr 25 12:51:53 kernel: pgd = ffffffc008c16000
Apr 25 12:51:53 kernel: [00000000] *pgd=000000001000d003, *pud=000000001000d003, *pmd=0000000010c7d003, *pte=0000000000000000
Apr 25 12:51:53 kernel: CPU: 1 PID: 8189 Comm: dcd Tainted: P O 4.1.27 #2
Apr 25 12:51:53 kernel: Hardware name: Broadcom-v8A (DT)
Apr 25 12:51:53 kernel: task: ffffffc014ab0b00 ti: ffffffc008244000 task.ti: ffffffc008244000
Apr 25 12:51:53 kernel: PC is at 0xf711ef44
Apr 25 12:51:53 kernel: LR is at 0x1dc74
Apr 25 12:51:53 kernel: pc : [<00000000f711ef44>] lr : [<000000000001dc74>] pstate: 600e0010
Apr 25 12:51:53 kernel: sp : 00000000ff9f3718
Apr 25 12:51:53 kernel: x12: 000000000009ff08
Apr 25 12:51:53 kernel: x11: 00000000f63ff024 x10: 00000000000a02ac
Apr 25 12:51:53 kernel: x9 : 00000000f63ff8c8 x8 : 00000000000a0764
Apr 25 12:51:53 kernel: x7 : 00000000f63ff900 x6 : 00000000000a075e
Apr 25 12:51:53 kernel: x5 : 0000000000000000 x4 : 00000000f63ff8ac
Apr 25 12:51:53 kernel: x3 : 0000000000000000 x2 : 00000000ff9f36f4
Apr 25 12:51:53 kernel: x1 : 000000000007c66c x0 : 0000000000000000
 
Log for a dcd crash below & I have not done a full factory reset with 384.11 alpha4 flash.

Apr 25 12:51:53 kernel: dcd[8189]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Apr 25 12:51:53 kernel: pgd = ffffffc008c16000
Apr 25 12:51:53 kernel: [00000000] *pgd=000000001000d003, *pud=000000001000d003, *pmd=0000000010c7d003, *pte=0000000000000000
Apr 25 12:51:53 kernel: CPU: 1 PID: 8189 Comm: dcd Tainted: P O 4.1.27 #2
Apr 25 12:51:53 kernel: Hardware name: Broadcom-v8A (DT)
Apr 25 12:51:53 kernel: task: ffffffc014ab0b00 ti: ffffffc008244000 task.ti: ffffffc008244000
Apr 25 12:51:53 kernel: PC is at 0xf711ef44
Apr 25 12:51:53 kernel: LR is at 0x1dc74
Apr 25 12:51:53 kernel: pc : [<00000000f711ef44>] lr : [<000000000001dc74>] pstate: 600e0010
Apr 25 12:51:53 kernel: sp : 00000000ff9f3718
Apr 25 12:51:53 kernel: x12: 000000000009ff08
Apr 25 12:51:53 kernel: x11: 00000000f63ff024 x10: 00000000000a02ac
Apr 25 12:51:53 kernel: x9 : 00000000f63ff8c8 x8 : 00000000000a0764
Apr 25 12:51:53 kernel: x7 : 00000000f63ff900 x6 : 00000000000a075e
Apr 25 12:51:53 kernel: x5 : 0000000000000000 x4 : 00000000f63ff8ac
Apr 25 12:51:53 kernel: x3 : 0000000000000000 x2 : 00000000ff9f36f4
Apr 25 12:51:53 kernel: x1 : 000000000007c66c x0 : 0000000000000000
How often do you get these? I ask because I get dcd tainted logs and I am still on 384.8_2. I only get them once a week or so and just ignore them. I have not moved to 384.9 or above because of this reported error, but my understanding is it happens a lot on this FW version and above. I will be trying 384.11 when it hits beta and hope to see little or no dcd tainted (i.e. have it not get worse than it already is).

I need stability since I work from home, but I will try betas (only after a couple days to see if anyone has a critical issue).
 
How often do you get these? I ask because I get dcd tainted logs and I am still on 384.8_2. I only get them once a week or so and just ignore them. I have not moved to 384.9 or above because of this reported error, but my understanding is it happens a lot on this FW version and above. I will be trying 384.11 when it hits beta and hope to see little or no dcd tainted (i.e. have it not get worse than it already is).

I need stability since I work from home, but I will try betas (only after a couple days to see if anyone has a critical issue).
As many have reported, this crash does not affect stability. I am 100% stable, no lock ups or reboots until I perform a flash. The dcd crash simply spams your log file, there is a script you can put in to to remove the crashes from the log. I get these anywhere from 2 minutes apart to 30 minutes apart.

I have Adaptive QOS, AiProtection turned on, I know if I turn these off the dcd crashes will stop. I had them off for a while but decided since the crashes just spam the log file I would rather have those features on.

I was hoping to get someone to clearly let me know if the the dcd crashes stopped or are continuing to happen with this firmware 45713. There have been entries of logs being clear but I cannot determine if those people were getting the dcd crashes prior. I was trying to get this answer to know if it would be worth while to perform a factory reset.
 
Last edited:
Does anybody see any unsual behaviour around Memory consumption? Running latest Merlin I've been hovering around 55% Memory utilization, going back to latest stock FW I started at around 55% increasing 1% every day after reboot. Right now I am running at 59%. No QoS, no AIMesh, no AiProtect.
I could reboot to turn this back to 55% but was wondering if anybody sees sam behaviour. Thanks!
 
Last edited:
As many have reported, this crash does not affect stability. I am 100% stable, no lock ups or reboots until I perform a flash. The dcd crash simply spams your log file, there is a script you can put in to to remove the crashes from the log. I get these anywhere from 2 minutes apart to 30 minutes apart.

I have Adaptive QOS, AiProtection turned on, I know if I turn these off the dcd crashes will stop. I had them off for a while but decided since the crashes just spam the log file I would rather have those features on.

I was hoping to get someone to clearly let me know if the the dcd crashes stopped or are continuing to happen with this firmware 45713. There have been entries of logs being clear but I cannot determine if those people were getting the dcd crashes prior. I was trying to get this answer to know if it would be worth while to perform a factory reset.

There are no log errors here including no dcd log errors running 45713 with AiProtection enabled. No one has posted of such errors. Consider yourself clearly informed by some anonymous person on an Internet forum. Now what are you going to do... take 20 minutes to upgrade your own router or keep fretting about it... decisions, decisions.

OE
 
Does anybody see any unsual behaviour around Memory consumption? Running latest Merlin I've been hovering around 55% Memory utilization, going back to latest stock FW I started at around 55% increasing 1% every day after reboot. Right now I am running at 59%. No QoS, no AIMesh, no AiProtect.
I could reboot to turn this back to 55% but was wondering if anybody sees sam behaviour. Thanks!

After raching 65% Memory utilisation with no additional traffic or clients connecting I decided to go back to latest Merlin for now - will check and compare to see if I can isolate reasons for this odd behaviour ...
 
After raching 65% Memory utilisation with no additional traffic or clients connecting I decided to go back to latest Merlin for now - will check and compare to see if I can isolate reasons for this odd behaviour ...

What router are you using?

What is your reason for being concerned with this? Linux will manage the RAM as it needs to.

On an RT-AC86U, I'm using a 2GB swap file with about 120MB used and 28MB RAM available right now. The network has never been so stable or so fast and responsive. ;)

Don't worry that the firmware is using the available physical resources fully. :)
 
@ L&LD - thanks for your response. I am running an RT-AC86U too, shelf-config, no changes to swap etc. I am not truly concerned but knew that memory utilisation has been standle with previous Merlin FW's, actually never ran stock FW on the device up until recently. Now with the recent FW release was curious and figured the continous increas without any obvious reason. As stated I changed back to Merling for now but may give it another try and see via console if I can identify any top processes....
 
@ L&LD - thanks for your response. I am running an RT-AC86U too, shelf-config, no changes to swap etc. I am not truly concerned but knew that memory utilisation has been standle with previous Merlin FW's, actually never ran stock FW on the device up until recently. Now with the recent FW release was curious and figured the continous increas without any obvious reason. As stated I changed back to Merling for now but may give it another try and see via console if I can identify any top processes....

Note that RMerlin states that you can flash to his firmware fork without doing a full reset to factory defaults. However, when going from RMerlin to stock, you must do a full reset, because of the extra settings/variables RMerlin uses which stock Asus firmware doesn't.
 
Also, regarding the 86U "dcd errors" showing in the system log file: I believe that @RMerlin has said that they are in fact present in both his and the stock version of 45713, but are visible in his version because the default log level shown is different (debug vs. info). So essentially, Asus has decided it is simpler to hide the error from view, rather than truly fix the problem.
 
no DCD error messages in log, AIProtection enabled, aqos enabled etc.
 
no DCD error messages in log, AIProtection enabled, aqos enabled etc.
Are you sure they won't show up if you change the viewable log level to debug and let it run several hours? I haven't tried the stock version, but that was my understanding of what Rmerlin said...
 
Also, regarding the 86U "dcd errors" showing in the system log file: I believe that @RMerlin has said that they are in fact present in both his and the stock version of 45713, but are visible in his version because the default log level shown is different (debug vs. info). So essentially, Asus has decided it is simpler to hide the error from view, rather than truly fix the problem.

well, that's unfortunate.
 
Are you sure they won't show up if you change the viewable log level to debug and let it run several hours? I haven't tried the stock version, but that was my understanding of what Rmerlin said...
In Asus firmware i can't saw option to change log level. In default mode no dcd messages.
 
In Asus firmware i can't saw option to change log level. In default mode no dcd messages.
Ah, ok....it has been so long since I have spent more than a few minutes on a stock firmware that I didn't realize that was not a configurable option.
 
Also, regarding the 86U "dcd errors" showing in the system log file: I believe that @RMerlin has said that they are in fact present in both his and the stock version of 45713, but are visible in his version because the default log level shown is different (debug vs. info). So essentially, Asus has decided it is simpler to hide the error from view, rather than truly fix the problem.
Thank you for posting this, I missed @RMerlin's info.
 
I believe that @RMerlin has said that they are in fact present in both his and the stock version of 45713, but are visible in his version because the default log level shown is different (debug vs. info).

No, I never said that. I have no idea if Asus did or did not fix the issue in 45713. In fact, I have never been able to even reproduce it myself.
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

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