[23.05-rc2] wifi shutdown on TPLINK (ath79 generic) on IRQ 23 not handled

[hhasert]

Describe the bug

The same happened on previous releases, the IRQ23 was not handled, but before it was just a kernel log message and nobody cared, but in this release (I think related to 5.15 kernel since I had it on snapshots before) when it happens it shuts down all wifi which ia a bad thing in a teams call ;-)

OpenWrt version

r23228-cd17d8df2a

OpenWrt target/subtarget

ath79/generic

Device

TP-Link Archer C7 v2

Image kind

Official downloaded image

Steps to reproduce

Just wait for it to happen (took mine less than a day)

Actual behaviour

The wifi just shuts down and in the kernel log you see :

[87765.218511] irq 23: nobody cared (try booting with the "irqpoll" option)
[87765.225331] CPU: 0 PID: 317 Comm: irq/23-keys Not tainted 5.15.118 #0
[87765.231874] Stack : 00000000 00000004 00000000 00000000 00000000 00000000 00000000 00000000
[87765.240373] 00000000 00000000 00000000 00000000 00000000 00000001 80c0b92 d1e8e1bf
[87765.248874] 80c0b9b8 00000000 00000000 80c0b7c0 00000038 8032d404 00000000 ffffffea
[87765.257375] 00000181 80c0b7cc 00000181 80720078 80660820 80c0b900 00000017 807846e0
[87765.265876] 0000001f 80790b68 80784480 80780000 00000018 80399288 00000000 808d0000
[87765.274377] ...
[87765.276859] Call Trace:
[87765.276870] [<8032d404>] 0x8032d404
[87765.282891] [<80399288>] 0x80399288
[87765.286469] [<800665b4>] 0x800665b4
[87765.290008] [<800665bc>] 0x800665bc
[87765.293545] [<800c51e8>] 0x800c51e8
[87765.297084] [<800c5704>] 0x800c5704
[87765.300619] [<8032da34>] 0x8032da34
[87765.304159] [<800c2970>] 0x800c2970
[87765.307695] [<800c5de4>] 0x800c5de4
[87765.311231] [<8032da34>] 0x8032da34
[87765.314770] [<800c5de4>] 0x800c5de4
[87765.318308] [<800c2034>] 0x800c2034
[87765.321846] [<80346cd8>] 0x80346cd8
[87765.325383] [<800c2970>] 0x800c2970
[87765.328921] [<800c2034>] 0x800c2034
[87765.332459] [<800c2970>] 0x800c2970
[87765.335995] [<8032da34>] 0x8032da34
[87765.339536] [<800c1ff0>] 0x800c1ff0
[87765.343071] [<8064c184>] 0x8064c184
[87765.346608] [<800c2034>] 0x800c2034
[87765.350146] [<8032d6d8>] 0x8032d6d8
[87765.353683] [<8032da34>] 0x8032da34
[87765.357230] [<80062198>] 0x80062198
[87765.360768] [<800c1ff0>] 0x800c1ff0
[87765.364304] [<8032da34>] 0x8032da34
[87765.367842] [<80346cd8>] 0x80346cd8
[87765.371380] [<8064c184>] 0x8064c184
[87765.374938] [<80511c48>] 0x80511c48
[87765.378476] [<8061a168>] 0x8061a168
[87765.382010] [<8032d42c>] 0x8032d42c
[87765.385549] [<8063a0fc>] 0x8063a0fc
[87765.389093] [<80511c48>] 0x80511c48
[87765.392644] [<8046e13c>] 0x8046e13c
[87765.396188] [<8046d9f8>] 0x8046d9f8
[87765.399724] [<80511c48>] 0x80511c48
[87765.403276] [<8046e530>] 0x8046e530
[87765.406822] [<80511c48>] 0x80511c48
[87765.410373] [<805108fc>] 0x805108fc
[87765.413913] [<80511b34>] 0x80511b34
[87765.417452] [<8050b9f4>] 0x8050b9f4
[87765.420997] [<8050c55c>] 0x8050c55c
[87765.424533] [<8050c6a4>] 0x8050c6a4
[87765.428076] [<8050bf7c>] 0x8050bf7c
[87765.431622] [<8050ce54>] 0x8050ce54
[87765.435166] [<80470484>] 0x80470484
[87765.438710] [<8006c578>] 0x8006c578
[87765.442249] [<804706cc>] 0x804706cc
[87765.445793] [<80413100>] 0x80413100
[87765.449337] [<80470d14>] 0x80470d14
[87765.452880] [<80471060>] 0x80471060
[87765.456416] [<8047126c>] 0x8047126c
[87765.459952] [<800c0000>] 0x800c0000
[87765.463492] [<8064c2f4>] 0x8064c2f4
[87765.467028] [<800c71dc>] 0x800c71dc
[87765.470568] [<800c0000>] 0x800c0000
[87765.474112] [<8032d6d8>] 0x8032d6d8
[87765.477656] [<800c3244>] 0x800c3244
[87765.481195] [<80062198>] 0x80062198
[87765.484737]
[87765.486246] handlers:
[87765.488543] [<85257547>] 0x800c29a0 threaded [<5c6328a2>] 0x80ffe0b8 [gpio_button_hotplug@4cf73d00+0x1a00]
[87765.498364] Disabling IRQ #23

Expected behaviour

I don't care about irq23 and nobody does it says, but I don't want Wifi to shut down, very annoying in a teams call.

Additional info

It did this on 22.03.5 but then it did not shutdown wifi, I noticed this earlier on snapshot releases using kernel 5.15.

Diffconfig

No response

Terms

• I am reporting an issue for OpenWrt, not an unsupported fork.

[hhasert]

see also #12167 and #11191

[DragonBluep]

This patch should fix the issue. Could you help to test it? And please report whether wifi kill switch works normally.

treewide-correct-rfkill-switch-event-to-SW_RFKILL_ALL.patch

Fixes: #13010
Fixes: #12167
Fixes: #11191
Fixes: #7835
Fixes: #7014

[hhasert]

I don't build myself, so cannot use a patch file. Can you tell me which snapshot contains the fix ? Some instruction how to test would be welcome as well, I only now see that it occurs a while after upgrading. I assume you mean to flip the wifi switch on the back and see if it kills wifi after applying the patch ?

[DragonBluep]

I don't build myself, so cannot use a patch file. Can you tell me which snapshot contains the fix ? Some instruction how to test would be welcome as well, I only now see that it occurs a while after upgrading.

You can try this file.
openwrt-ath79-generic-tplink_archer-c7-v2.tar.gz

I assume you mean to flip the wifi switch on the back and see if it kills wifi after applying the patch ?

Yes.
If it doesn't have any problems in three days, then I think this fix works.

[Djfe]

Problems meaning: wifi disabling itself during the three days due to the irq
Sure the switch still needs to work (you can test enabling/disabling), but it shouldn't be triggered without being touched like it's right now

[hhasert]

Is this a sysupgrade based on 23.05-rc2 with just the patch or a snapshot ? (ah, the zip contains a sysupgrade :-)
So, I just apply it and monitor a few days to see if I see the IRQ issue repeats (which would be shutting down my WiFi so wont be missed ;-) I do not need to check if the wifi button on the back panel is still functional ? (I don't think anyone actually uses that switch anyway)

[DragonBluep]

I do not need to check if the wifi button on the back panel is still functional ?

Please check whether the button can turn on/off the radio. It's very important since this patch is based on fixing the function of the WiFi switch.

[hhasert]

Ok, so I apply the patch, wait 3 days to see if the IRQ23 triggers (since that is my reported bug) and after that I try if the switch is still functional. I deployed it and I will tell you in a couple of days.

[5-7] so far no issues with IRQ23, will test the wifi switch tomorrow.

[hhasert]

Probably unrelated, I get "Unable to execute opkg install command: SyntaxError: Unexpected end of JSON input" whenever I install a package (but it does seem to install without issues). I reflashed because it eventually broke things, but now I dont seem to get the error.
Only when I upgrade luci-app-system it gives some errors on unexpected tokens (so I will not do that again).
There is probably some ongoing work on Luci, so unrelated to this issue, just have to wait for it to stabilize again.

[hhasert]

I tried the wifi switch today, while running nothing changes when I flip the switch, so I hope this is expected behavior.

[DragonBluep]

Probably unrelated, I get "Unable to execute opkg install command: SyntaxError: Unexpected end of JSON input" whenever I install a package (but it does seem to install without issues). I reflashed because it eventually broke things, but now I dont seem to get the error. Only when I upgrade luci-app-system it gives some errors on unexpected tokens (so I will not do that again). There is probably some ongoing work on Luci, so unrelated to this issue, just have to wait for it to stabilize again.

Official package source is not compatible with the self-build image, this is the expected behavior. I remember opkg should provide some force install options to install them.

I tried the wifi switch today, while running nothing changes when I flip the switch, so I hope this is expected behavior.

I made a mistake before, OpenWrt has a local button detection implement. Can you try this new fix?
archer-c7-v2.tar.gz

At least now we can confirm that this issue is caused by the WiFi switch.

[hhasert]

I will run the new package 3 days again I assume to see if the IRQ23 is still solved ? After that I will flip the switch to see the difference.
Can you tell me why the wifi switch would just trigger without anyone touching it, is that just a glitch of the system of something in the pre-patched software ?

After a while (not updating anything) luci throws the unexpected token again (this time in dashboard). Seems like you are right that it is not aligned with a personal build. Anyway, I will run the tests and then return to a safer build again. Luci probably has trouble parsing the output of some command it executes.

[DragonBluep]

I will run the new package 3 days again I assume to see if the IRQ23 is still solved ? After that I will flip the switch to see the difference. Can you tell me why the wifi switch would just trigger without anyone touching it, is that just a glitch of the system of something in the pre-patched software ?

This may be a hardware issue, something like pull-up resistor causing the GPIO to be incorrectly pulled down? I'm not very sure. At the worst, we need to disable the WiFi button.

[hhasert]

This may be a hardware issue, something like pull-up resistor causing the GPIO to be incorrectly pulled down? I'm not very sure. At the worst, we need to disable the WiFi button.

I was wondering about that. I never use the wifi switch anyway since shutting down can be done with luci or a script. I would rather have the button disabled to avoid interrupted wifi. I don't see it yet on this build and typically I get it the first few days. I will continue to run it to see if I get a spurious wifi disable. Would it be possible to configure the button action off in the config so a user can choose to disable it when it is causing issues ?

The switch is working perfectly, so that part is solved. No errors in the log files, no IRQ23 type of problems, so I think the patch is a go, just wondering why the other spurious issue seems to be solved as well. Maybe me physically flipping it has removed some dust :-) Would this work to disable it (or another suggestion perhaps)

chmod -x /etc/rc.button/rfkill ??

From syslog :
Fri Jul 7 10:06:30 2023 daemon.notice hostapd: Remove interface 'phy1-ap0'
Fri Jul 7 10:06:30 2023 daemon.notice hostapd: phy1-ap0: interface state ENABLED->DISABLED
Fri Jul 7 10:06:30 2023 daemon.notice hostapd: phy1-ap0: AP-DISABLED
Fri Jul 7 10:06:30 2023 daemon.notice hostapd: phy1-ap0: CTRL-EVENT-TERMINATING
Fri Jul 7 10:06:30 2023 daemon.err hostapd: rmdir[ctrl_interface=/var/run/hostapd]: Permission denied

It logs this after flipping the switch for both interfaces. It enables them again on the next flip of the switch.

[DragonBluep]

I was wondering about that. I never use the wifi switch anyway since shutting down can be done with luci or a script. I would rather have the button disabled to avoid interrupted wifi.

Disabling WiFi switch will annoy some users. There are still someone needs it.

Would it be possible to configure the button action off in the config so a user can choose to disable it when it is causing issues ?

You can directly delete/rename file /etc/rc.button/rfkill to avoid the rfkill action. IRQ23 warning logs may still exists, however you can ignore it as it is just a warning.

I have tried many times, but still cannot reproduce this problem. This issue seems to be caused by gpio-button-hotplug package not responding to the interrupt. The underlying reason should be that switch button was accidentally triggered multiple times in one second (hardware issue).

The current workaround is to longer the debounce time to 1000 ms. I am unable to confirm whether my theory is correct so I don't want to push it to the mainline. Hope some Archer C7 users can test it more and push it. At lease it seems work for @hhasert

--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -16,7 +16,7 @@
                gpios = <&gpio 23 GPIO_ACTIVE_LOW>;
                linux,code = <KEY_RFKILL>;
                linux,input-type = <EV_SW>;
-               debounce-interval = <60>;
+               debounce-interval = <1000>;
        };
 };

[hhasert]

Thx, renamed it to rfkill.no :-) It looks like a fix for me at least indeed, no more spurious button detection and a working wifi kill switch. Hope it can be tested by the other people that reported it, since there are multiple bug reports for the same issue.

[DragonBluep]

@hhasert can you help to try this version and show me these outputs. Finally, I would like to check if the registers are correct. You do not need to take the 3-day test(If you are willing, it would be very grateful).
archer-c7-v2.tar.gz

root@OpenWrt:~# dmesg |grep irq
[    0.324919] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 2500000) is a 16550A
[    1.233818] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
[    1.594122] eth1: Atheros AG71xx at 0xba000000, irq 5, mode: gmii
[    4.043115] bdata irq: 17, button irq: 0, irq flags: 0x00002003
[    4.043855] irq type: 0x00000003, gpio mask: 0x00020000
[   13.040689] ieee80211 phy0: Atheros AR9340 Rev:1 mem=0xb8100000, irq=2
root@OpenWrt:~# devmem 0x18040014 32
0x00020000
root@OpenWrt:~# devmem 0x18040018 32
0x00000000
root@OpenWrt:~# devmem 0x1804001c 32
0x00000000
root@OpenWrt:~# devmem 0x18040020 32
0x00000000
root@OpenWrt:~# devmem 0x18040024 32
0x00020000

[hhasert]

On the previous download :

root@Router-Boven:~#  dmesg |grep irq
[    0.298679] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 2500000) is a 16550A
[    1.482746] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
[    1.833912] eth1: Atheros AG71xx at 0xba000000, irq 5, mode: sgmii
[    4.294824] ehci-platform 1b000000.usb: irq 14, io mem 0x1b000000
[    4.352823] ehci-platform 1b400000.usb: irq 15, io mem 0x1b400000
[   44.115220] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
[   50.406973] ieee80211 phy1: Atheros AR9550 Rev:0 mem=0xb8100000, irq=12

devmem is not installed in that image. I will flash the new one later today and post the results.

[hhasert]

The new release :

root@Router-Boven:~# dmesg |grep irq
[    0.298596] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 2500000) is a 16550A
[    1.472584] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: rgmii
[    1.823721] eth1: Atheros AG71xx at 0xba000000, irq 5, mode: sgmii
[    4.259768] bdata irq: 16, button irq: 0, irq flags: 0x00002003
[    4.259961] irq type: 0x00000003, gpio mask: 0x00010000
[    4.271445] bdata irq: 23, button irq: 0, irq flags: 0x00002003
[    4.271622] irq type: 0x00000003, gpio mask: 0x00800000
[    4.322896] ehci-platform 1b000000.usb: irq 14, io mem 0x1b000000
[    4.382627] ehci-platform 1b400000.usb: irq 15, io mem 0x1b400000
[   44.247002] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0
[   50.607503] ieee80211 phy1: Atheros AR9550 Rev:0 mem=0xb8100000, irq=12
root@Router-Boven:~# devmem 0x18040014 32
0x00810000
root@Router-Boven:~# devmem 0x18040018 32
0x00000000
root@Router-Boven:~# devmem 0x1804001c 32
0x00800000
root@Router-Boven:~# devmem 0x18040020 32
0x00000000
root@Router-Boven:~# devmem 0x18040024 32
0x00810000

Curious why I see the bdata entries for the buttons in this release and not the previous one....

Can I stay on this snapshot or do I need to flash the 23.05-rc2 again and just remove the rfkill button script ??

[DragonBluep]

Curious why I see the bdata entries for the buttons in this release and not the previous one....

Can I stay on this snapshot or do I need to flash the 23.05-rc2 again and just remove the rfkill button script ??

Thanks for letting me know. The register values are correct. I have inserted some debugging code in the latest firmware.

If this doesn't bother you, I hope you can continue testing this firmware for a few days. It should no longer have irq23 issue.

[Djfe]

Been following this thread closely, I hope I get around to testing this.
I have 3 Archer C7 v2 and one v5 here. And also a TD-W8970B. (All with an RF-Kill switch on the back)
EDIT: C7 v5 doesn't have a kill switch.
If useful: I have a friend, owning a wdr4300

[DragonBluep]

Been following this thread closely, I hope I get around to testing this. I have 3 Archer C7 v2 and one v5 here. And also a TD-W8970B. (All with an RF-Kill switch on the back) EDIT: C7 v5 doesn't have a kill switch. If useful: I have a friend, owning a wdr4300

Hi @Djfe, have you noticed irq23 issue before?

[Djfe]

Kind of. it's far from my daily driver. I'm engaging with Freifunk (Gluon fork) and heard about wifi on these devices sometimes being off. Triggering the switch twice (same position) would turn wifi on again 😅
I haven't looked at logread when that happened, yet. But now that you are working on a fix, I feel tempted to take a closer look (before and after installing the snapshot with your fix).
I didn't know exactly where to start fixing the switch related code, so this was in my backlog of things I wanted to do/fix.

[DragonBluep]

@Djfe Haha, let's just pending this issue and let some developers which have rich knowledge to fix it. It's a hardware/software mixture issue. If we cannot manually trigger it. Debugging will be very difficult. At leaset I have checked the ath79 gpio driver but not find any bugs.

P.S. Set bit to GPIO_INT_TYPE register will trigger this warning. Howerver, if the program runs normally, the value of this register will always be 0.

P.P.S. A workaround: #13010 (comment)

[hhasert]

So, no more IRQ23 errors detected. Conclusion is correct that the issue is caused by the wifi switch triggering without being touched. I hope you can convince someone to put it in the mainline code.

[DragonBluep]

So, no more IRQ23 errors detected. Conclusion is correct that the issue is caused by the wifi switch triggering without being touched. I hope you can convince someone to put it in the mainline code.

Okay, I'll give it a try. Do you want to add a Tested-by commit tag to record your contribution? If so, perhaps you can provide your name and email(not mandatory).

[hhasert]

Okay, I'll give it a try. Do you want to add a Tested-by commit tag to record your contribution? If so, perhaps you can provide your name and email(not mandatory).

Sure, no problem. My name is Hans Hasert. I would rather not publish my email, got enough spam already ;-)

[DragonBluep]

I have sent the patch to the mailing list.
http://lists.openwrt.org/pipermail/openwrt-devel/2023-July/041271.html
https://patchwork.ozlabs.org/project/openwrt/patch/TYAP286MB0315F6A4041644748C17192ABC34A@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM/

[Djfe]

I'll check eventually if I can find other affected routers.
And test my archer c7 v2 and then report back here.
Yeah, I didn't get around to it, yet. 🙄 Thanks for pushing this along

[ceedveed]

I'm encountering the same problem on archer c7 v2:

Sat Sep 30 18:29:18 2023 kern.err kernel: [27744.432076] irq 23: nobody cared (try booting with the "irqpoll" option)
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.438886] CPU: 0 PID: 427 Comm: irq/23-keys Not tainted 5.10.176 #0
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.445414] Stack : 00000001 800bf948 80760000 806597ac 00000000 00000000 00000000 00000000
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.453905] 00000000 00000000 00000000 00000000 00000000 00000001 80c09db8 52f531ad
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.462397] 80c09e50 00000000 00000000 80c09c60 00000038 8032ad24 00000000 ffffffea
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.470888] 000000e4 80c09c6c 000000e4 806e9b48 80c09d98 80631e58 00000000 807521b0
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.479381] 0000001f 8075e8a8 80751f50 80750000 00000018 80391d64 00000000 808a0000
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.487873] ...
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.490355] Call Trace:
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.490365] [<800bf948>] 0x800bf948
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.496378] [<8032ad24>] 0x8032ad24
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.499915] [<80391d64>] 0x80391d64
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.503484] [<8006698c>] 0x8006698c
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.507016] [<80066994>] 0x80066994
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.510553] [<800c5154>] 0x800c5154
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.514092] [<800c5624>] 0x800c5624
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.517629] [<800c2970>] 0x800c2970
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.521166] [<800c5d18>] 0x800c5d18
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.524706] [<800c2014>] 0x800c2014
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.528244] [<8034125c>] 0x8034125c
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.531780] [<800c2014>] 0x800c2014
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.535316] [<800c2014>] 0x800c2014
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.538854] [<8032b34c>] 0x8032b34c
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.542391] [<800c7104>] 0x800c7104
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.545930] [<800c2014>] 0x800c2014
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.549467] [<8061e134>] 0x8061e134
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.553005] [<8032b030>] 0x8032b030
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.556547] [<80062518>] 0x80062518
Sat Sep 30 18:29:18 2023 kern.warn kernel: [27744.560080]
Sat Sep 30 18:29:18 2023 kern.err kernel: [27744.561590] handlers:
Sat Sep 30 18:29:18 2023 kern.err kernel: [27744.563893] [<51639936>] 0x800c29a0 threaded [<1f4b37e6>] 0x80fd80b8 [gpio_button_hotplug@c652faf3+0x19c0]
Sat Sep 30 18:29:18 2023 kern.emerg kernel: [27744.573692] Disabling IRQ #23
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: Remove interface 'wlan0'
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: wlan0: interface state ENABLED->DISABLED
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 60:e9:aa:08:8a:e1
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: wlan0: AP-DISABLED
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Sat Sep 30 18:29:18 2023 daemon.err hostapd: rmdir[ctrl_interface=/var/run/hostapd]: Permission denied
Sat Sep 30 18:29:18 2023 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Sat Sep 30 18:29:18 2023 kern.info kernel: [27745.085980] device wlan0 left promiscuous mode
Sat Sep 30 18:29:18 2023 kern.info kernel: [27745.090633] br-lan: port 2(wlan0) entered disabled state
Sat Sep 30 18:29:18 2023 kern.info kernel: [27745.097463] ath10k_pci 0000:00:00.0: mac flush vdev 0 drop 0 queues 0x1 ar->paused: 0x0 arvif->paused: 0x0
Sat Sep 30 18:29:18 2023 daemon.notice netifd: Network device 'wlan0' link is down
Sat Sep 30 18:29:19 2023 kern.info kernel: [27745.110207] ath10k_pci 0000:00:00.0: mac flush null vif, drop 0 queues 0xffff
Sat Sep 30 18:29:19 2023 daemon.notice netifd: Wireless device 'radio0' is now down

OpenWrt 22.03.5 r20134-5f15225c1e / LuCI openwrt-22.03 branch git-23.093.57104-ce20b4a
ath79/generic

Is the fix just to rename the file above?: /etc/rc.button/rfkill

EDIT:
Currently testing the rename. I am a novice linux user. I first logged in to openwrt through Putty on Windows. Then I cd to /etc/rc.button. Then I used command mv rfkill rfkill_backup. Lastly, reboot.

[hhasert]

renaming the file should prevent the WiFi going down, but the actual fix is to change the detection of the button timeout which was submitted but still in review because I personally think ' nobody cares' is the correct description in the log.

[parttimehorse]

Issue is present for me on Archer C7 v2 as well, the renaming as described above seems to work as a workaround so far. However, I also think the proposed patch linked in #13010 (comment) should be reviewed / merged as a proper fix