Router Model Affected
Models: ZenWiFi_XT8 (base model: RT-AX95Q)
Firmware Version Affected
Version : 388.2_beta1
Is this bug present in upstream Merlin releases too?
IDK
Describe the bug
Every night I reboot my XT8 mesh nodes auomatically. Usually I can work without issues during the day. Today the whole mesh (3 nodes) froze, and after rebooting I notice the following :
May 11 15:20:20 kernel: potentially unexpected fatal signal 11.
May 11 15:20:20 kernel: CPU: 2 PID: 1880 Comm: httpd Tainted: P O 4.1.52 #1
May 11 15:20:20 kernel: Hardware name: Generic DT based system
May 11 15:20:20 kernel: task: d105f400 ti: d10d8000 task.ti: d10d8000
May 11 15:20:20 kernel: PC is at 0xb6a7cb10
May 11 15:20:20 kernel: LR is at 0x4a908
May 11 15:20:20 kernel: pc : [] lr : [<0004a908>] psr: 20030010
May 11 15:20:20 kernel: sp : beff2e30 ip : 000b7188 fp : b65da0de
May 11 15:20:20 kernel: r10: beff2fa8 r9 : 000a470a r8 : 00000000
May 11 15:20:20 kernel: r7 : beff2ef0 r6 : beff2f10 r5 : 001f1928 r4 : 0022ca40
May 11 15:20:20 kernel: r3 : b68537f4 r2 : 00000000 r1 : 00000000 r0 : 0022ca40
May 11 15:20:20 kernel: Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
May 11 15:20:20 kernel: Control: 10c5387d Table: 1112004a DAC: 00000015
May 11 15:20:20 kernel: CPU: 2 PID: 1880 Comm: httpd Tainted: P O 4.1.52 #1
May 11 15:20:21 kernel: Hardware name: Generic DT based system
May 11 15:20:21 kernel: [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
May 11 15:20:21 kernel: [] (show_stack) from [] (dump_stack+0x8c/0xa0)
May 11 15:20:21 kernel: [] (dump_stack) from [] (get_signal+0x490/0x558)
May 11 15:20:21 kernel: [] (get_signal) from [] (do_signal+0xc8/0x3ac)
May 11 15:20:21 kernel: [] (do_signal) from [] (do_work_pending+0x94/0xa4)
May 11 15:20:21 kernel: [] (do_work_pending) from [] (work_pending+0xc/0x20)
May 11 15:20:26 watchdog: restart httpd
etc
The issue with unexpected fatal signal 11 is/was Trendmicro related I found out on https://www.snbforums.com/threads/potentially-unexpected-fatal-signal-11.66482/
I have now applied nvram set TM_EULA=0 via prompt, but this is only a temporary solution as long the router doesnt reboot.
Expected behavior
I would haev thought Asus/Trendmicro would have fixed the issue in later firmwares already.
Router Model Affected Models: ZenWiFi_XT8 (base model: RT-AX95Q)
Firmware Version Affected Version : 388.2_beta1
Is this bug present in upstream Merlin releases too? IDK
Describe the bug Every night I reboot my XT8 mesh nodes auomatically. Usually I can work without issues during the day. Today the whole mesh (3 nodes) froze, and after rebooting I notice the following : May 11 15:20:20 kernel: potentially unexpected fatal signal 11. May 11 15:20:20 kernel: CPU: 2 PID: 1880 Comm: httpd Tainted: P O 4.1.52 #1 May 11 15:20:20 kernel: Hardware name: Generic DT based system May 11 15:20:20 kernel: task: d105f400 ti: d10d8000 task.ti: d10d8000 May 11 15:20:20 kernel: PC is at 0xb6a7cb10 May 11 15:20:20 kernel: LR is at 0x4a908 May 11 15:20:20 kernel: pc : [] lr : [<0004a908>] psr: 20030010
May 11 15:20:20 kernel: sp : beff2e30 ip : 000b7188 fp : b65da0de
May 11 15:20:20 kernel: r10: beff2fa8 r9 : 000a470a r8 : 00000000
May 11 15:20:20 kernel: r7 : beff2ef0 r6 : beff2f10 r5 : 001f1928 r4 : 0022ca40
May 11 15:20:20 kernel: r3 : b68537f4 r2 : 00000000 r1 : 00000000 r0 : 0022ca40
May 11 15:20:20 kernel: Flags: nzCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
May 11 15:20:20 kernel: Control: 10c5387d Table: 1112004a DAC: 00000015
May 11 15:20:20 kernel: CPU: 2 PID: 1880 Comm: httpd Tainted: P O 4.1.52 #1
May 11 15:20:21 kernel: Hardware name: Generic DT based system
May 11 15:20:21 kernel: [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
May 11 15:20:21 kernel: [] (show_stack) from [] (dump_stack+0x8c/0xa0)
May 11 15:20:21 kernel: [] (dump_stack) from [] (get_signal+0x490/0x558)
May 11 15:20:21 kernel: [] (get_signal) from [] (do_signal+0xc8/0x3ac)
May 11 15:20:21 kernel: [] (do_signal) from [] (do_work_pending+0x94/0xa4)
May 11 15:20:21 kernel: [] (do_work_pending) from [] (work_pending+0xc/0x20)
May 11 15:20:26 watchdog: restart httpd
etc
The issue with unexpected fatal signal 11 is/was Trendmicro related I found out on https://www.snbforums.com/threads/potentially-unexpected-fatal-signal-11.66482/
I have now applied nvram set TM_EULA=0 via prompt, but this is only a temporary solution as long the router doesnt reboot.
Expected behavior I would haev thought Asus/Trendmicro would have fixed the issue in later firmwares already.
Will keep an eye on the behaviour.