What's new

Crashlog on GS-AX3000. Can you decipher?

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

dwp

Regular Contributor
Hello all and thanks in advance for any pointers on this...

My relatively new GS-AX3000 with latest stock AsusWRT sometimes crashes. Last night it did it a 5pm pretty much on the dot. I was able to extract the crashlog entries from syslog - ignore the date/time shown as I guess these are written without reference to NTP stuff.

It looks to me that the main thing is a null pointer reference on line 557 where it reads: "May 4 22:05:04 crashlog: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000043". But I am sure no expert. Most of this is greek to me.

Thankfully, the syslog also contained previous crashlog instances. They also have a null pointer reference saying "May 4 22:05:04 crashlog: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000043".

So maybe there is something repeatable happening here?

Can anyone suggest what might be up with this?

Thanks
 
What is in the log just prior to the crash? The last several line may give you a clue as to what the router was doing when it crashed.
 
What is in the log just prior to the crash? The last several line may give you a clue as to what the router was doing when it crashed.
Good question! It is always looking like this:

Code:
Oct 27 03:27:22 HMA: Download version info failed, retry=[4]
Oct 27 03:27:25 HMA: Download version info failed, retry=[3]
Oct 27 03:27:27 HMA: Download version info failed, retry=[2]
Oct 27 03:27:30 HMA: Download version info failed, retry=[1]
Oct 27 03:27:32 HMA: Download version info failed, retry=[0]
Oct 27 03:27:38 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7346)]retrieve firmware information
Oct 27 03:27:38 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7360)]fimrware update check first time
Oct 27 03:27:38 WATCHDOG: [FAUPGRADE][auto_firmware_check:(7388)]no need to upgrade firmware

followed by a bunch of stuff like this (generally for many MACs):

Code:
Oct 27 05:00:13 wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:E6:2D:97:E1:E5, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Oct 27 05:00:13 wlceventd: wlceventd_proc_event(508): eth5: Disassoc xx:E6:2D:97:E1:E5, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

Oct 27 05:00:17 wlceventd: wlceventd_proc_event(527): eth5: Auth xx:E6:2D:97:E1:E5, status: Successful (0), rssi:0

I find this interesting because what looks to be the stack trace is:

Code:
May  4 22:05:04 crashlog: <2>eth3 (Int switch port: 3) (Logical Port: 3) (phyId: b) Link DOWN.
May  4 22:05:04 crashlog: <6>br0: port 1(eth3) entered disabled state
May  4 22:05:04 crashlog: <1>Unable to handle kernel NULL pointer dereference at virtual address 00000043
May  4 22:05:04 crashlog: <1>pgd = c0014000
May  4 22:05:04 crashlog: <1>[00000043] *pgd=00000000
May  4 22:05:04 crashlog: <0>Internal error: Oops: 17 [#1] PREEMPT SMP ARM
May  4 22:05:04 crashlog: <4>CPU: 0 PID: 18500 Comm: kworker/u6:0 Tainted: P           O    4.1.52 #2
May  4 22:05:04 crashlog: <4>Hardware name: Generic DT based system
May  4 22:05:04 crashlog: <4>Workqueue: linkwatch linkwatch_event
May  4 22:05:04 crashlog: <4>task: d46f7800 ti: d21ec000 task.ti: d21ec000
May  4 22:05:04 crashlog: <4>PC is at _fc_update_stats+0x74/0x41c [pktflow]
May  4 22:05:04 crashlog: <4>LR is at fc_evict+0xc4/0x5a8 [pktflow]

I am certainly no expert. But it seems like the failure is happening in something called linkwatch. And I presume that this is what might cause the link down and disabled messages. Of course, that would require someone with much more knowledge to ascertain for sure.

Thanks!
 
This is still happening. I wish someone from Asus would read, respond, and fix this.
 
This is still happening. I wish someone from Asus would read, respond, and fix this.
Asus isn't present on these forums.
 
Thanks. I have also posted to the ROG forums. They don't appear to be there either!

I've used the "Feedback" form in the web admin interface "Administration" section. Have gotten responses from Asus from submitting bugs and issues there. Not all the time, I expect that once they've got enough input on particualar bugs they stop responding, figure that they've got what they need to fix their bugs. Anyways, there's another channel to Asus support.
 
I've used the "Feedback" form in the web admin interface "Administration" section. Have gotten responses from Asus from submitting bugs and issues there. Not all the time, I expect that once they've got enough input on particualar bugs they stop responding, figure that they've got what they need to fix their bugs. Anyways, there's another channel to Asus support.
Thanks. I have done that as well. Never even got a confirmation email from Asus. I did today contact Asus on this via "chat". All that person wanted me to do is factory reset my router. I finally just attached the log file and told him to look at a specific line number where the null pointer was seen. I knew he could do nothing so just asked that he forward all the info to the right party. I am not holding my breath. But I can still hope...
 

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