What's new

AX86u resets the uptime clock-should I be worried?

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

Lee MacMillan

Senior Member
Another AX86u owner started a similar thread about this that didn't get many responses so I am starting another one. My AX86u went online on March 4th. Since then, this event (I'm not sure if it is an actual reboot or not since it last has happened 4 or 5 times, all but one time when I was not actively using the internet. The latest was last night at 11:07 p.m. after I went to bed and 30 minutes after the last active use of the internet via streaming. There are 6 or 8 IoT devices online constantly but generally not active. I am running Merlin 386.1_2 and have been for at least 2 weeks. A section of the system log just before and just after the event is below. It had been a little over 5 days since the last time this occurred. (This morning the router uptime reads 11 hours as an indicator that everything was reset). Note how the date changes from the current date to May 5.

I'm wondering it this indicates a potential hardware problem in my AX86u or is it a bug in the firmware (either the Asus code or the Merlin code)? Since at least one other user has had the same issue (and I think with two different units), it appears that my situation is not unique.

Mar 22 21:59:42 kernel: CONSOLE: 581214.981 wl1.0: wlc_send_bar: for d8:31:34:37:fd:dc seq 0x4e7 tid 4 (this MAC is my Roku Ultra)
Mar 22 21:59:42 kernel: CONSOLE: 581214.981 wl1.0: wlc_send_bar: for d8:31:34:37:fd:dc seq 0x2b5 tid 5
Mar 22 21:59:42 kernel: CONSOLE: 581214.981 wl1.0: wlc_send_bar: for d8:31:34:37:fd:dc seq 0x874 tid 6
Mar 22 21:59:42 kernel: CONSOLE: 581214.981 wl1.0: wlc_send_bar: for d8:31:34:37:fd:dc seq 0x72 tid 7
Mar 22 21:59:42 kernel: CONSOLE: 581214.981 wlc_mutx_active_update vasip mu_supported_Ntx 4
Mar 22 21:59:42 kernel: CONSOLE: 581214.982 HWA1a RxPOST: H2D RxPost ring: id<1> type<0> item_type<1> max_items<1024> len_item<8>
Mar 22 21:59:42 kernel: CONSOLE: 581214.982 HWA1a RxPOST: item_size 8 CWI32 config parser<00000000> format<0> size<8>
Mar 22 21:59:42 kernel: CONSOLE: 581214.982 HWA1a RxPOST: rxpost_data_buf_len<1836>
Mar 22 21:59:42 kernel: CONSOLE: 581214.985 MQ: wlc_tx_fifo_sync_complete: TXPENDTOT = 4
Mar 22 21:59:42 kernel: CONSOLE: 581214.985 MQ: wlc_tx_fifo_sync_complete: fifo 0: collected 1 pkts
Mar 22 21:59:42 kernel: CONSOLE: 581214.985 MQ: wlc_tx_fifo_sync_complete: fifo 1: collected 2 pkts
Mar 22 21:59:42 kernel: CONSOLE: 581214.985 MQ: wlc_tx_fifo_sync_complete: fifo 2: collected 1 pkts
Mar 22 21:59:42 kernel: CONSOLE: 581214.985 MQ: wlc_tx_fifo_sync_complete: fifo 3: collected 0 pkts
Mar 22 21:59:42 kernel: CONSOLE: 581214.986 CSIMON: already initialized ...
Mar 22 21:59:42 kernel: CONSOLE: 581214.996 wl1: link up (wl1)
Mar 22 21:59:42 kernel: CONSOLE: 581214.996 wl1: link up (wl1.1)
Mar 22 21:59:42 kernel: CONSOLE: 581216.083 wl1: wlc_send_bar_complete: no tx attempted, txstatus: 0x15
Mar 22 21:59:42 kernel: CONSOLE: 581216.086 wl1.0: wlc_send_bar: for 58:cb:52:96:9d:50 seq 0x32d tid 0
Mar 22 21:59:42 kernel: CONSOLE: 581216.096 wl1: wlc_send_bar_complete: no tx attempted, txstatus: 0x15
Mar 22 21:59:42 kernel: CONSOLE: 581216.096 wl1.0: wlc_send_bar: for 58:cb:52:96:9d:50 seq 0x794 tid 1
Mar 22 21:59:42 kernel: CONSOLE: 581216.096 wl1: wlc_send_bar_complete: no tx attempted, txstatus: 0x15
Mar 22 21:59:42 kernel: CONSOLE: 581216.096 wl1.0: wlc_send_bar: for 58:cb:52:96:9d:50 seq 0x20 tid 2
Mar 22 21:59:42 kernel: CONSOLE: 581216.270 wl1: wlc_send_bar_complete: no tx attempted, txstatus: 0x15
Mar 22 21:59:42 kernel: CONSOLE: 581216.270 wl1.0: wlc_send_bar: for f8:0f:f9:f4:ea:9e seq 0x43 tid 2
Mar 22 22:07:26 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link DOWN.
Mar 22 22:07:30 kernel: eth1 (Ext switch port: 0) (Logical Port: 8) (phyId: 8) Link Up at 1000 mbps full duplex
May 5 01:05:08 kernel: klogd started: BusyBox v1.25.1 (2021-02-12 17:47:23 EST)
May 5 01:05:08 crashlog: LOG
May 5 01:05:08 crashlog: <4>PC is at fc_fdb_hashin+0x10c/0x1c0 [pktflow]
May 5 01:05:08 crashlog: <4>LR is at fc_fdb_hashin+0xfc/0x1c0 [pktflow]
May 5 01:05:08 kernel: npe_max_entries<32768>
May 5 01:05:08 kernel: Bind blog_notify_evt_enqueue_fn[<ffffffbffc469888>]
May 5 01:05:08 crashlog: <4>pc : [<ffffffbffc44c49c>] lr : [<ffffffbffc44c48c>] pstate: 80000145
May 5 01:05:08 kernel: fc_evt task created successfully
May 5 01:05:08 crashlog: <4>sp : ffffffc03e8cb000
May 5 01:05:08 kernel: max_ent = 16384 intvl_msec = 10000 num_slices = 2000 num_ent = 9 period_msec = 5
May 5 01:05:08 kernel: NBUFF v1.0 Initialized
May 5 01:05:08 crashlog: <4>x29: ffffffc03e8cb000 x28: 0000000000000000
May 5 01:05:08 kernel: ^[[0;36;44mTotal # of labels = 68^[[0m
May 5 01:05:08 crashlog: <4>x27: 00000000ffff0000 x26: 0000000000000000
May 5 01:05:08 kernel: ^[[0;36;44mInitialized fcache state^[[0m
May 5 01:05:08 kernel: Pkt HW acceleration is disabled/unavailable.
May 5 01:05:08 crashlog: <4>x25: ffffffc0305e0200 x24: ffffff80010c8100
May 5 01:05:08 kernel: ^[[0;36;44mBroadcom Packet Flow Cache Char Driver v4.0 Registered<302>^[[0m
.
. (I did not reprint a large number of lines. Below is just before the "event" ended.)
.
May 5 01:05:16 avahi-daemon[1957]: Alias name "RT-AX86U" successfully established.
May 5 01:05:16 kernel: +++++ BRCM skipping port_feat_c_connection for warm reset
May 5 01:05:16 kernel: NOHZ: local_softirq_pending 08
May 5 01:05:16 kernel: NOHZ: local_softirq_pending 08
May 5 01:05:16 kernel: NOHZ: local_softirq_pending 08
May 5 01:05:16 kernel: NOHZ: local_softirq_pending 08
May 5 01:05:17 ntpd: Started ntpd
May 5 01:05:17 kernel: scsi 0:0:0:0: Direct-Access SanDisk Ultra 1.00 PQ: 0 ANSI: 6
May 5 01:05:17 kernel: sd 0:0:0:0: [sda] 60063744 512-byte logical blocks: (30.8 GB/28.6 GiB)
May 5 01:05:17 kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
May 5 01:05:17 kernel: sd 0:0:0:0: [sda] Write Protect is off
May 5 01:05:17 kernel: sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
May 5 01:05:17 kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk
May 5 01:05:18 acsd: eth6: COEX: downgraded chanspec 0x1808 (6) to 0x1006 (6): channel 3 used by exiting BSSs
May 5 01:05:18 acsd: eth6: selected channel spec: 0x1006 (6)
May 5 01:05:18 acsd: eth6: Adjusted channel spec: 0x1006 (6)
May 5 01:05:18 acsd: eth6: selected channel spec: 0x1006 (6)
May 5 01:05:18 acsd: acs_set_chspec: 0x1006 (6) for reason APCS_INIT (The time from start to finish on the May 5 date is only 10 seconds)
Mar 22 22:09:14 ntpd: Initial clock set (The system clock indicates the event lasted 1 minute 44 seconds vs 10 seconds for the "event" clock)
Mar 22 22:09:14 rc_service: ntpd_synced 2268:notify_rc restart_diskmon
Mar 22 22:09:14 disk_monitor: Finish
 
Last edited:
Your router crashed and rebooted. Try going back to a more stable firmware release or using the current beta.

The timestamps look correct. The last log entry was at 22:07:30 so the reboot happened at some time after this. Also, it takes about a minute for the router to reboot before the syslog starts up. Try manually rebooting the router through to GUI and compare the timestamps.
 
Last edited:
You router crashed and rebooted. Try going back to a more stable firmware release or using the current beta.

The timestamps look correct. The last log entry was at 22:07:30 so the reboot happened at some time after this. Also, it takes about a minute for the router to reboot before the syslog starts up. Try manually rebooting the router through to GUI and compare the timestamps.
How do I determine a more stable firmware? Trial and error? Or do I just flash the 386.2 beta and see how it behaves? FWIW, I just rebooted and it took exactly 1:30 for it to come back to the GUI login screen.
 
...interesting, all four my AX86Us that are running stock fw have been up for months since the last fw update... and were similarly perfectly stable for many months before that going back to when they were first set up. My settings are very basic though. It could be a fw setting corruption issue when you moved to Merlin or it could be a bug when using particular settings that effects both stock Asus and Merlin... or just Merlin. Maybe Merlin would have more advice and information about this.
 
Last edited:
This is why I stick with official Asus firmware. My 86u has been totally solid since september and I only now decide to upgrade the firmware on it
 
I flashed Merlin 386.2 a week ago, did a factory reset and re-configured from scratch. I've gone over 7 days without a spontaneous reboot. It never went more than 5 days previously and sometimes went less than 24 hours between reboots I had previously dirty flashed (i.e., no factory reset) Merlin over the stock firmware. It appears that was the issue.
 

Sign Up For SNBForums Daily Digest

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