cancel
Showing results for 
Search instead for 
Did you mean: 

GT-AX11000 Stalling

keiichi25
Level 7
First time seeing the router itself stalling.

On my side, the network was unresponsive, including the router's web interface. Could not even talk to the Cable modem via ip or otherwise.

After rebooting the router, system log showed the following:

Jul 4 15:15:57 kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 3, t=60006 jiffies, g=28202045, c=28202044, q=9370)
Jul 4 15:15:57 kernel: Call trace:
Jul 4 15:15:57 kernel: [] __switch_to+0x64/0x80
...
Jul 4 15:51:57 kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1, t=2220062 jiffies, g=28202045, c=28202044, q=252000)
Jul 4 15:51:57 kernel: Call trace:
Jul 4 15:51:57 kernel: [] __switch_to+0x64/0x80
Jul 4 15:54:57 kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 2, t=2400071 jiffies, g=28202045, c=28202044, q=272395)
Jul 4 15:54:57 kernel: Call trace:
Jul 4 15:54:57 kernel: [] __switch_to+0x64/0x80
Jul 4 15:57:57 kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} (detected by 1, t=2580072 jiffies, g=28202045, c=28202044, q=292541)
Jul 4 15:57:57 kernel: Call trace:
Jul 4 15:57:57 kernel: [] __switch_to+0x64/0x80


Rebooted router manually and able to get control back, but curious what could have caused it.

Did check prior to the initial start of the issue and only saw the following in the log:

Jul 4 03:54:18 WATCHDOG: [FAUPGRADE][auto_firmware_check:(6110)]retrieve firmware information
Jul 4 03:54:18 WATCHDOG: [FAUPGRADE][auto_firmware_check:(6124)]no need to upgrade firmware
Jul 4 11:55:36 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc xx:xx:xx:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jul 4 11:55:36 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc xx:xx:xx:xx:xx:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)


So I have nothing else to really show what may have caused a problem.

Router would have had about a 8-9 day run time.
11,094 Views
4 REPLIES 4

Alaxang
Level 7
I noticed this as well with my AX11000. Using it as router mode, (Randomly)the router would just disconnect my network from the ONT(the lights on the router is showing normal operation, no alert or anything). A reboot will usually get my network connection back. Right now I am using it under AP mode(still monitoring) no disconnection so far.
The run time is around 1 weeks before I start to see such instability.

Using the latest firmware from official website.

So following up, had another stall, but was able to sort of 'observe' it as it was happening.

In this case, I was on, my desktop and laptop were wired into the router and a pixel book connected via the 5GHz connection.

I get told the internet is down by someone using the 2.4 GHz connection, and verified I couldn't connect to the 2.4 GHz connection.

Was able to get to the router, and saw in the logs the following:


Jul 10 17:52:48 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:49 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:50 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:51 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:52 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:53 acsd: acs_update_status(920): acs get chanspec failed ret code: -16
Jul 10 17:52:53 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:54 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:55 acsd: acsd_chanim_query(773): failed to get chanim resultsret code: -16
Jul 10 17:52:55 rc_service: httpd 11729:notify_rc restart_wireless
Jul 10 17:52:57 kernel: ubi1: attaching mtd10
Jul 10 17:52:57 kernel: ubi1: scanning is finished
Jul 10 17:52:57 kernel: ubi1: attached mtd10 (name "misc1", size 8 MiB)
Jul 10 17:52:57 kernel: ubi1: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
Jul 10 17:52:57 kernel: ubi1: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
Jul 10 17:52:57 kernel: ubi1: VID header offset: 2048 (aligned 2048), data offset: 4096
Jul 10 17:52:57 kernel: ubi1: good PEBs: 64, bad PEBs: 0, corrupted PEBs: 0
Jul 10 17:52:57 kernel: ubi1: user volume: 1, internal volumes: 1, max. volumes count: 128
Jul 10 17:52:57 kernel: ubi1: max/mean erase counter: 6/2, WL threshold: 4096, image sequence number: 1091345526
Jul 10 17:52:57 kernel: ubi1: available PEBs: 0, total reserved PEBs: 64, PEBs reserved for bad PEB handling: 4
Jul 10 17:52:57 kernel: ubi1: background thread "ubi_bgt1d" started, PID 15499
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" started, PID 15516
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "nvram"
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): FS size: 5840896 bytes (5 MiB, 46 LEBs), journal size 1396736 bytes (1 MiB, 11 LEBs)
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): reserved for root: 0 bytes (0 KiB)
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): media format: w4/r0 (latest is w4/r0), UUID 92D70055-D40E-4496-A698-DA48D5E57B93, small LPT model
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): un-mount UBI device 1
Jul 10 17:52:58 kernel: UBIFS (ubi1:0): background thread "ubifs_bgt1_0" stops
Jul 10 17:52:58 kernel: ubi1: detaching mtd10
Jul 10 17:52:58 kernel: ubi1: mtd10 is detached
Jul 10 17:53:00 acsd: Selecting 2g band ACS policy
Jul 10 17:53:03 acsd: selected channel spec: 0x100b (11)
Jul 10 17:53:03 acsd: Adjusted channel spec: 0x100b (11)
Jul 10 17:53:03 acsd: selected channel spec: 0x100b (11)
Jul 10 17:53:03 acsd: acs_set_chspec: 0x100b (11) for reason APCS_INIT
Jul 10 17:53:03 acsd: Selecting 5g band ACS policy
May 4 22:05:10 kernel: klogd started: BusyBox v1.24.1 (2019-06-12 09:43:05 CST)


Near the end, I was trying to set the WiFi settings as per ASUS tech support request when the system then went completely unresponsive, which include the wired connections.

I rebooted the system and was able to get back into the system, but found the multiple "failed to get chanim resultsret code: -16" entries, and this was going on from 16:20 to 17:53 (which is where I was forced to reboot the Router) is similar to the other multiple error states from before, before the network stack apparently takes a major nose dive.

This suggests the router is having some issues over time and starts flailing and gets into a bad state loop, although generating two different kind of failure loops.

keiichi25 wrote:
So following up, had another stall, but was able to sort of 'observe' it as it was happening.

In this case, I was on, my desktop and laptop were wired into the router and a pixel book connected via the 5GHz connection.

I get told the internet is down by someone using the 2.4 GHz connection, and verified I couldn't connect to the 2.4 GHz connection.

Was able to get to the router, and saw in the logs the following:



Near the end, I was trying to set the WiFi settings as per ASUS tech support request when the system then went completely unresponsive, which include the wired connections.

I rebooted the system and was able to get back into the system, but found the multiple "failed to get chanim resultsret code: -16" entries, and this was going on from 16:20 to 17:53 (which is where I was forced to reboot the Router) is similar to the other multiple error states from before, before the network stack apparently takes a major nose dive.

This suggests the router is having some issues over time and starts flailing and gets into a bad state loop, although generating two different kind of failure loops.



I've had the same issue, but I guess I've fixed this - I was about to return this , As support chat just sucks - Here's what you've to do

Under Advance settings goto WAN ---- > WAN DNS Setting - Add Google DNS Name Servers or Cloudflare DNS
8.8.8.8
8.8.4.4

Cloudflare
1.1.1.1
1.0.0.1

Under Advance Settings goto ----- > Special Requirement from ISP --------- > DHCP query frequency and set to NORMAL
Under Advance Settings goto ----- > Basic Config --------- > Enable UPNP to NO

Apply and after just reboot the router - Everything will work just fine after that.

Well, in the end, I ended up having to get it warranty replaced. The replacement router does not seem to have the problem and while the suggestion to set the DNS was meant in good faith, the problem is, if the router does a full stall, IE, does not even allow for access to the web interface, the issue is hardly a DNS issue.