Release Asuswrt-Merlin 3004.388.4 is now available

[kriukas]

I noticed on 3004.388.4 version, that after some time, router httpds service hangs and doesn't restart by itself. I can restart from ssh command line manually though. The only clue in logs:

Nov 19 12:42:08 GT-AXE16000 kernel: potentially unexpected fatal signal 11.
Nov 19 12:42:08 GT-AXE16000 kernel: CPU: 3 PID: 4805 Comm: httpds Tainted: P O 4.19.183 #1
Nov 19 12:42:08 GT-AXE16000 kernel: Hardware name: GTAXE16000_2GB (DT)
Nov 19 12:42:08 GT-AXE16000 kernel: pstate: 80070010 (Nzcv q A32 LE aif)
Nov 19 12:42:08 GT-AXE16000 kernel: pc : 0000000000052aac
Nov 19 12:42:08 GT-AXE16000 kernel: lr : 0000000000052a94
Nov 19 12:42:08 GT-AXE16000 kernel: sp : 00000000ffecf808
Nov 19 12:42:08 GT-AXE16000 kernel: x12: 00000000000d22c4
Nov 19 12:42:08 GT-AXE16000 kernel: x11: 0000000000c12ab0 x10: 0000000000052958
Nov 19 12:42:08 GT-AXE16000 kernel: x9 : 00000000ffecfb22 x8 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x7 : 00000000ffecf8fc x6 : 00000000ffecfa87
Nov 19 12:42:08 GT-AXE16000 kernel: x5 : 0000000000e5bbd0 x4 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x3 : 00000000000b22f6 x2 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x1 : 00000000f76a07b0 x0 : 0000000000000000

- does any one experienced this also? Any insights?

 

[IroMan]

I have that one and nothing like that.

I noticed on 3004.388.4 version, that after some time, router httpds service hangs and doesn't restart by itself. I can restart from ssh command line manually though. The only clue in logs:

Nov 19 12:42:08 GT-AXE16000 kernel: potentially unexpected fatal signal 11.
Nov 19 12:42:08 GT-AXE16000 kernel: CPU: 3 PID: 4805 Comm: httpds Tainted: P O 4.19.183 #1
Nov 19 12:42:08 GT-AXE16000 kernel: Hardware name: GTAXE16000_2GB (DT)
Nov 19 12:42:08 GT-AXE16000 kernel: pstate: 80070010 (Nzcv q A32 LE aif)
Nov 19 12:42:08 GT-AXE16000 kernel: pc : 0000000000052aac
Nov 19 12:42:08 GT-AXE16000 kernel: lr : 0000000000052a94
Nov 19 12:42:08 GT-AXE16000 kernel: sp : 00000000ffecf808
Nov 19 12:42:08 GT-AXE16000 kernel: x12: 00000000000d22c4
Nov 19 12:42:08 GT-AXE16000 kernel: x11: 0000000000c12ab0 x10: 0000000000052958
Nov 19 12:42:08 GT-AXE16000 kernel: x9 : 00000000ffecfb22 x8 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x7 : 00000000ffecf8fc x6 : 00000000ffecfa87
Nov 19 12:42:08 GT-AXE16000 kernel: x5 : 0000000000e5bbd0 x4 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x3 : 00000000000b22f6 x2 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x1 : 00000000f76a07b0 x0 : 0000000000000000

- does any one experienced this also? Any insights?

 

[Viktor Jaep]

I posted this in its own thread, but perhaps it's better to include this issue here as well. Running 388.4 on a GT-AX6000.

I seem to get these kinds of errors quite frequently while running scripts on my GT-AX6000. When these pop up, it basically stops scripts in their tracks, and locks them until I break out of them. It's random, sometimes happening within a few minutes... other times, many many hours before I see them.

Like with my ol' RT-AC86U and it's strange script hang-ups, I guess the GT-AX6000 isn't immune. After a reboot, they stay away for a while, but eventually come back. Has anyone encountered these, and/or know of a way to fix this error? I'm sure it's a bug of sorts... and luckily the timeout command seems to be able to get around them... but it would be nice not to have to use these workarounds.

 

[MNoisy]

I noticed on 3004.388.4 version, that after some time, router httpds service hangs and doesn't restart by itself. I can restart from ssh command line manually though. The only clue in logs:

Nov 19 12:42:08 GT-AXE16000 kernel: potentially unexpected fatal signal 11.
Nov 19 12:42:08 GT-AXE16000 kernel: CPU: 3 PID: 4805 Comm: httpds Tainted: P O 4.19.183 #1
Nov 19 12:42:08 GT-AXE16000 kernel: Hardware name: GTAXE16000_2GB (DT)
Nov 19 12:42:08 GT-AXE16000 kernel: pstate: 80070010 (Nzcv q A32 LE aif)
Nov 19 12:42:08 GT-AXE16000 kernel: pc : 0000000000052aac
Nov 19 12:42:08 GT-AXE16000 kernel: lr : 0000000000052a94
Nov 19 12:42:08 GT-AXE16000 kernel: sp : 00000000ffecf808
Nov 19 12:42:08 GT-AXE16000 kernel: x12: 00000000000d22c4
Nov 19 12:42:08 GT-AXE16000 kernel: x11: 0000000000c12ab0 x10: 0000000000052958
Nov 19 12:42:08 GT-AXE16000 kernel: x9 : 00000000ffecfb22 x8 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x7 : 00000000ffecf8fc x6 : 00000000ffecfa87
Nov 19 12:42:08 GT-AXE16000 kernel: x5 : 0000000000e5bbd0 x4 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x3 : 00000000000b22f6 x2 : 0000000000000000
Nov 19 12:42:08 GT-AXE16000 kernel: x1 : 00000000f76a07b0 x0 : 0000000000000000

- does any one experienced this also? Any insights?

Two AXE-16000's in our network and haven't seen that on the newest alpha.

 

[Martinski]

I posted this in its own thread, but perhaps it's better to include this issue here as well. Running 388.4 on a GT-AX6000.

I seem to get these kinds of errors quite frequently while running scripts on my GT-AX6000. When these pop up, it basically stops scripts in their tracks, and locks them until I break out of them. It's random, sometimes happening within a few minutes... other times, many many hours before I see them.

Like with my ol' RT-AC86U and it's strange script hang-ups, I guess the GT-AX6000 isn't immune. After a reboot, they stay away for a while, but eventually come back. Has anyone encountered these, and/or know of a way to fix this error? I'm sure it's a bug of sorts... and luckily the timeout command seems to be able to get around them... but it would be nice not to have to use these workarounds.

Are you saying that those errors are definitely coming from "nvram" or "wl" commands getting "stuck" on the GT-AX6000, like the ones that happen on the RT-AC86U?

I would have hoped the AX routers had that problem fixed already. A real bummer if that problem still persists in the latest F/W releases.

 

[Viktor Jaep]

Are you saying that those errors are definitely coming from "nvram" or "wl" commands getting "stuck" on the GT-AX6000, like the ones that happen on the RT-AC86U?

I would have hoped the AX routers had that problem fixed already. A real bummer if that problem still persists in the latest F/W releases.

I still can't say for sure. Still trying to determine what exactly is the cause... the PID it references in the error disappears quite quick, and have not been able to catch what its referring to. I did start incorporating more "timeout" wrappers around the nvram/wl commands in response to this, but I've had instances where this error still caused a lock. So either it doesn't care about "timeout" either, or it's hanging for some other reason.

I rebooted my router after many weeks of uptime, and the error has gone away for now... but it will be back at some point. Since it's such an usual error, I thought I'd report it through the chain here...

 

[colossus]

AX86U Pro - Merlin 3004.388.4 - Uptime 106+ days
Merlin consistently performs as expected over time.
Thank you @RMerlin

 

[Dedel66]

Are you aware that 388.5 is online?

 

[colossus]

Acknowledged. While I am aware that version 388.5 is available, we have decided to remain on version 388.4 for the time being. Our current version has been stable, ensuring consistent uptime and optimal performance for our modest network. We appreciate the advancements in the newer version but prioritize the reliability and smooth operation of our existing setup at this time. We will continue to monitor future updates and assess their compatibility with our system requirements. Good day.

 

[rktchip]

There's a bug on XT12 where the LED settings wouldn't survive a reboot. I will need to manually off the LED light on ASUSWRT again after router reboot . Low priority bug.

The bug used to exist of ASUS official firmware and ASUS fixed it.

I tried the latest December Merlin firmware 3004.388.5 and this bug is still present for my XT12. Is this bug too device specific or is it possible it will be fixed in the future?

 

[HeadBanger]

I tried the latest December Merlin firmware 3004.388.5 and this bug is still present for my XT12. Is this bug too device specific or is it possible it will be fixed in the future?

Same here for two RT-AX86U nodes. I just use the ASUS app (which reports them as ‘off’) to turn on the LEDs (which are already on) and then toggle them to off. An annoying bug for sure!

HB

 

[SomeWhereOverTheRainBow]

Same here for two RT-AX86U nodes. I just use the ASUS app (which reports them as ‘off’) to turn on the LEDs (which are already on) and then toggle them to off. An annoying bug for sure!

HB

You know what they say, leave a couple annoying bugs for job security.

 

[Unetwork]

I agree with @colossus about version 3004.388.4. It is still rock solid on my AX88U for 102 days.
I've also decided to stick with version 388.4 for the time being.
Thanks again to Merlin and the developers.