What's new

RT-AC86U Possible Kernel Crash

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

Neil62

Senior Member
Is there anybody that can explain the below, the router is currently using the latest firmware in amesh setup:

Dec 29 14:27:44 kernel: pgd = ffffffc009274000
Dec 29 14:27:44 kernel: [00000000] *pgd=0000000012834003, *pud=0000000012834003, *pmd=000000000b385003, *pte=0000000000000000
Dec 29 14:27:44 kernel: CPU: 1 PID: 10416 Comm: dcd Tainted: P O 4.1.27 #2
Dec 29 14:27:44 kernel: Hardware name: Broadcom-v8A (DT)
Dec 29 14:27:44 kernel: task: ffffffc01915cb00 ti: ffffffc0129b8000 task.ti: ffffffc0129b8000
Dec 29 14:27:45 kernel: PC is at 0xf734ef44
Dec 29 14:27:45 kernel: LR is at 0x1dc74
Dec 29 14:27:45 kernel: pc : [<00000000f734ef44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 29 14:27:45 kernel: sp : 00000000fffcbb48
Dec 29 14:27:45 kernel: x12: 000000000009ff10
Dec 29 14:27:45 kernel: x11: 00000000f65ff024 x10: 00000000000a02b4
Dec 29 14:27:45 kernel: x9 : 00000000f65ffab8 x8 : 00000000000a076c
Dec 29 14:27:45 kernel: x7 : 00000000f65ffaf0 x6 : 00000000000a0766
Dec 29 14:27:45 kernel: x5 : 0000000000000000 x4 : 00000000f65ffa9c
Dec 29 14:27:45 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 29 14:27:45 kernel: x1 : 000000000007c674 x0 : 0000000000000000
 
Is there anybody that can explain the below, the router is currently using the latest firmware in amesh setup:

Dec 29 14:27:44 kernel: pgd = ffffffc009274000
Dec 29 14:27:44 kernel: [00000000] *pgd=0000000012834003, *pud=0000000012834003, *pmd=000000000b385003, *pte=0000000000000000
Dec 29 14:27:44 kernel: CPU: 1 PID: 10416 Comm: dcd Tainted: P O 4.1.27 #2
Dec 29 14:27:44 kernel: Hardware name: Broadcom-v8A (DT)
Dec 29 14:27:44 kernel: task: ffffffc01915cb00 ti: ffffffc0129b8000 task.ti: ffffffc0129b8000
Dec 29 14:27:45 kernel: PC is at 0xf734ef44
Dec 29 14:27:45 kernel: LR is at 0x1dc74
Dec 29 14:27:45 kernel: pc : [<00000000f734ef44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 29 14:27:45 kernel: sp : 00000000fffcbb48
Dec 29 14:27:45 kernel: x12: 000000000009ff10
Dec 29 14:27:45 kernel: x11: 00000000f65ff024 x10: 00000000000a02b4
Dec 29 14:27:45 kernel: x9 : 00000000f65ffab8 x8 : 00000000000a076c
Dec 29 14:27:45 kernel: x7 : 00000000f65ffaf0 x6 : 00000000000a0766
Dec 29 14:27:45 kernel: x5 : 0000000000000000 x4 : 00000000f65ffa9c
Dec 29 14:27:45 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 29 14:27:45 kernel: x1 : 000000000007c674 x0 : 0000000000000000

Disable AiProtection and see if the log clears up.

OE
 
I saw that same sys log a lot with stock firmware. Not so much with Merlin firmware.
 
Disable AiProtection and see if the log clears up.

OE

And/Or Adaptive QoS, since that uses the Trend Micro engine too.

I was just thinking yesterday that maybe I should re-enable Adaptive QoS, that maybe this problem had been resolved (thought it was related to a bad signature file update) - but I guess I'll continue to leave it disabled.
 
And/Or Adaptive QoS, since that uses the Trend Micro engine too.

I was just thinking yesterday that maybe I should re-enable Adaptive QoS, that maybe this problem had been resolved (thought it was related to a bad signature file update) - but I guess I'll continue to leave it disabled.

Actually, the best way to disble the Trend Micro stuff is Administration\Privacy\Withdraw.

OE
 
Actually, the best way to disble the Trend Micro stuff is Administration\Privacy\Withdraw.

OE
It says that features may not work. Have you found that AiProtection and adaptive QOS still work if you withdraw? Thanks.
 
It says that features may not work. Have you found that AiProtection and adaptive QOS still work if you withdraw? Thanks.

Withdrawing turns OFF Trend Micro features. Turn 'em back ON as you use them. No big deal.

OE
 
And yet I'm still getting it in Merlin 384.19 with my new RT-AX3000. Just installed a few days ago and I didn't notice it at first. Is it me, or is this still an issue? Maybe my Merlin install/migration caused it? I'm trying to decide to do a clean M&M install but I don't want to be chasing known issues. It says above it was fixed in ASUS 384-45713 1.5 years ago. Surely that fix got ported into Merlin 384.19
 
And yet I'm still getting it in Merlin 384.19 with my new RT-AX3000.
I've just got the same error even on the stock firmware on RT-AX56U ("younger brother" of RT-AX3000). Look like caused by AiProtection Pro and still has not been properly fixed in the stock firmware.
 
And yet I'm still getting it in Merlin 384.19 with my new RT-AX3000. Just installed a few days ago and I didn't notice it at first. Is it me, or is this still an issue? Maybe my Merlin install/migration caused it? I'm trying to decide to do a clean M&M install but I don't want to be chasing known issues. It says above it was fixed in ASUS 384-45713 1.5 years ago. Surely that fix got ported into Merlin 384.19
It's in my AC86U .19 too. Searched it again and seems like I'm not the only one.
 
I see this issue in my logs on an AC86U and .19, came across this thread from a google search.

I use adaptive QOS just to use the upload/download bandwidth limiter, can I switch it to 'traditional' set the same option and use the 'withdraw' option for trend micro. Get rid of the issue and still use it all?
 

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