wlcore crashes after RT throttling

[Chraebi]

Dear all,

Unfortunately, my Beaglebone (especially wlcore) crashes regularly after RT throttling is enabled. The syslog looks as follows:

Feb 19 19:06:47 debian systemd[1]: Removed slice User Slice of debian.
Feb 19 19:12:22 debian hostapd: SoftAp0: STA 50:eb:71:d5:37:f2 IEEE 802.11: disassociated due to inactivity
Feb 19 19:12:23 debian hostapd: SoftAp0: STA 50:eb:71:d5:37:f2 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Feb 19 19:14:04 debian kernel: [  607.589484] sched: RT throttling activated
Feb 19 19:14:54 debian kernel: [  657.589610] wlcore: ERROR ELP wakeup timeout!
Feb 19 19:14:54 debian kernel: [  657.599703] ------------[ cut here ]------------
Feb 19 19:14:54 debian kernel: [  657.600010] WARNING: CPU: 0 PID: 1600 at drivers/net/wireless/ti/wlcore/main.c:796 wl12xx_queue_recovery_work.part.10+0x68/0x6c [wlcore]
Feb 19 19:14:54 debian kernel: [  657.600018] Modules linked in: aes_arm_bs crypto_simd cryptd xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 wl18xx wlcore mac80211 rfcomm bnep cfg80211 hci_uart btqca bluetooth ecdh_generic w1_therm w1_gpio wlcore_sdio evdev usb_f_mass_storage usb_f_acm u_serial iptable_nat nf_conntrack_ipv4 usb_f_ecm nf_defrag_ipv4 bc_example(O) nf_nat_ipv4 usb_f_rndis nf_nat u_ether nf_conntrack pvrsrvkm(O) libcomposite iptable_mangle iptable_filter uio_pdrv_genirq uio spidev pruss_soc_bus pru_rproc pruss pruss_intc ip_tables x_tables
Feb 19 19:14:54 debian kernel: [  657.600223] CPU: 0 PID: 1600 Comm: hostapd Tainted: G           O    4.14.108-ti-r113 #1
Feb 19 19:14:54 debian kernel: [  657.600229] Hardware name: Generic AM33XX (Flattened Device Tree)
Feb 19 19:14:54 debian kernel: [  657.600275] [<c0113180>] (unwind_backtrace) from [<c010d690>] (show_stack+0x20/0x24)
Feb 19 19:14:54 debian kernel: [  657.600296] [<c010d690>] (show_stack) from [<c0ce54b4>] (dump_stack+0x80/0x94)
Feb 19 19:14:54 debian kernel: [  657.600312] [<c0ce54b4>] (dump_stack) from [<c013f5b8>] (__warn+0xf8/0x110)
Feb 19 19:14:54 debian kernel: [  657.600325] [<c013f5b8>] (__warn) from [<c013f6e8>] (warn_slowpath_null+0x30/0x38)
Feb 19 19:14:54 debian kernel: [  657.600442] [<c013f6e8>] (warn_slowpath_null) from [<bf48af6c>] (wl12xx_queue_recovery_work.part.10+0x68/0x6c [wlcore])
Feb 19 19:14:54 debian kernel: [  657.600650] [<bf48af6c>] (wl12xx_queue_recovery_work.part.10 [wlcore]) from [<bf48e858>] (wl12xx_queue_recovery_work+0x24/0x28 [wlcore])
Feb 19 19:14:54 debian kernel: [  657.600817] [<bf48e858>] (wl12xx_queue_recovery_work [wlcore]) from [<bf499030>] (wl1271_ps_elp_wakeup+0x240/0x24c [wlcore])
Feb 19 19:14:54 debian kernel: [  657.600982] [<bf499030>] (wl1271_ps_elp_wakeup [wlcore]) from [<bf48816c>] (wlcore_op_set_key+0x78/0x134 [wlcore])
Feb 19 19:14:54 debian kernel: [  657.601630] [<bf48816c>] (wlcore_op_set_key [wlcore]) from [<bf3e7e08>] (ieee80211_key_enable_hw_accel+0x118/0x3f8 [mac80211])
Feb 19 19:14:54 debian kernel: [  657.602116] [<bf3e7e08>] (ieee80211_key_enable_hw_accel [mac80211]) from [<bf3e8880>] (ieee80211_key_link+0x16c/0x28c [mac80211])
Feb 19 19:14:54 debian kernel: [  657.602424] [<bf3e8880>] (ieee80211_key_link [mac80211]) from [<bf3d4e80>] (ieee80211_add_key+0x1b4/0x2b0 [mac80211])
Feb 19 19:14:54 debian kernel: [  657.603139] [<bf3d4e80>] (ieee80211_add_key [mac80211]) from [<bf2e4ecc>] (nl80211_new_key+0x144/0x34c [cfg80211])
Feb 19 19:14:54 debian kernel: [  657.603462] [<bf2e4ecc>] (nl80211_new_key [cfg80211]) from [<c0b9ef08>] (genl_rcv_msg+0x24c/0x44c)
Feb 19 19:14:54 debian kernel: [  657.603482] [<c0b9ef08>] (genl_rcv_msg) from [<c0b9dee8>] (netlink_rcv_skb+0xe0/0x114)
Feb 19 19:14:54 debian kernel: [  657.603498] [<c0b9dee8>] (netlink_rcv_skb) from [<c0b9ecac>] (genl_rcv+0x34/0x44)
Feb 19 19:14:54 debian kernel: [  657.603511] [<c0b9ecac>] (genl_rcv) from [<c0b9d5a4>] (netlink_unicast+0x19c/0x250)
Feb 19 19:14:54 debian kernel: [  657.603524] [<c0b9d5a4>] (netlink_unicast) from [<c0b9da04>] (netlink_sendmsg+0x2d4/0x3b4)
Feb 19 19:14:54 debian kernel: [  657.603544] [<c0b9da04>] (netlink_sendmsg) from [<c0b38730>] (sock_sendmsg+0x44/0x54)
Feb 19 19:14:54 debian kernel: [  657.603559] [<c0b38730>] (sock_sendmsg) from [<c0b391cc>] (___sys_sendmsg+0x23c/0x250)
Feb 19 19:14:54 debian kernel: [  657.603573] [<c0b391cc>] (___sys_sendmsg) from [<c0b3a354>] (__sys_sendmsg+0x60/0x9c)
Feb 19 19:14:54 debian kernel: [  657.603587] [<c0b3a354>] (__sys_sendmsg) from [<c0b3a3a8>] (SyS_sendmsg+0x18/0x1c)
Feb 19 19:14:54 debian kernel: [  657.603608] [<c0b3a3a8>] (SyS_sendmsg) from [<c0108d40>] (ret_fast_syscall+0x0/0x54)
Feb 19 19:14:54 debian kernel: [  657.615753] ---[ end trace 1c6afe2c155c40e4 ]---

Know I'm not sure if the wlcore crashes and then activates RT throttling or if another process crashes, which activates RT throttling and then wlcore crashes.

Is there a possibility to find out why RT throttling is activated?

Thank you for your help and kind regards

Chraebi