gnuton / asuswrt-merlin.ng

Extends the support of Merlin firmware to more ASUS routers
Other
1.48k stars 85 forks source link

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

Open dacootmeister opened 1 year ago

dacootmeister commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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