Zenwifi XT8 hangs after potentially unexpected fatal signal 11 with Gnuton 388.2_beta1

[dacootmeister]

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.

[gnuton]

try to nvram commit after using 'nvram set' or reset to factory and do not enable TM.

Please let me konw if thi helps or you have more logs.

[dacootmeister]

Ok @gnuton , followed your advise and keeping track of logs