Open manataji opened 6 months ago
Using the v5.6.4.2 driver, the following behavior was observed when CONFIG_PREEMPT_RT was enabled for the Linux kernel supporting the RT patch. The kernel version is 5.10.186-rt91 und rt patch applyed for 5.10.186.
■operation #!/bin/sh cat <<__EOT__ > /etc/hostapd.conf interface=wlan0 driver=nl80211 ctrl_interface=/var/run/hostapd macaddr_acl=0 ieee80211n=1 ieee80211ac=1 ieee80211w=1 wmm_enabled=1 ssid=test-ap_wpa11ch hw_mode=g channel=11 acs_num_scans=1 acs_chan_bias=1:0.8 6:0.8 11:0.8 chanlist=1 6 11 ht_capab=[SHORT-GI-20] beacon_int=100 max_num_sta=1 ignore_broadcast_ssid=0 auth_algs=1 wpa=2 wpa_passphrase=87654321 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP __EOT__ ifconfig wlan0 192.168.0.10 hostapd -i wlan0 -B /etc/hostapd.conf
■result [ 29.124617] Unable to handle kernel paging request at virtual address ffffffc01112701c [ 29.124622] Mem abort info: [ 29.124625] ESR = 0x96000021 [ 29.124628] EC = 0x25: DABT (current EL), IL = 32 bits [ 29.124633] SET = 0, FnV = 0 [ 29.124636] EA = 0, S1PTW = 0 [ 29.124639] Data abort info: [ 29.124641] ISV = 0, ISS = 0x00000021 [ 29.124644] CM = 0, WnR = 0 [ 29.124648] swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000000092d000 [ 29.124654] [ffffffc01112701c] pgd=000000000e03f003, p4d=000000000e03f003, pud=000000000e03f003, pmd=000000000186c003, pte=0068000001902703 [ 29.124674] Internal error: Oops: 96000021 [#1] PREEMPT_RT SMP [ 29.124680] Modules linked in: 88XXau(O) iscdrv(PO) mn_sdmmc [ 29.124698] CPU: 0 PID: 151 Comm: RTW_CMD_THREAD Tainted: P O 5.10.186-rt91 #1 [ 29.124706] Hardware name: ntcj,nep1 (DT) [ 29.124710] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--) [ 29.124718] pc : rt_spin_lock+0x54/0x90 [ 29.124737] lr : update_bmc_sta+0xf4/0x140 [88XXau] [ 29.124967] sp : ffffff8002813c10 [ 29.124970] x29: ffffff8002813c10 x28: ffffff8001948000 [ 29.124978] x27: 00000000002f3200 x26: 0000000000003800 [ 29.124985] x25: ffffffc0110a8640 x24: 0000000000000000 [ 29.124992] x23: 0000000000000000 x22: 0000000000000000 [ 29.124999] x21: 0000000000000001 x20: ffffffc0110a5000 [ 29.125006] x19: ffffffc011127004 x18: ffffffffffffffff [ 29.125013] x17: 0000000000000001 x16: 0000000000000001 [ 29.125020] x15: ffffffc010b0dec9 x14: ffffffffffffffff [ 29.125027] x13: ffffffc010b0dec0 x12: ffffffffffffb7df [ 29.125035] x11: ffffffc010a996e8 x10: ffffffc010a9e710 [ 29.125042] x9 : ffffff8002813c20 x8 : ffffff8002813c20 [ 29.125049] x7 : 000000000000000f x6 : 0000000000000009 [ 29.125055] x5 : ffffffc01112701c x4 : 0000000000000000 [ 29.125062] x3 : ffffffc011127004 x2 : ffffff80012b4f80 [ 29.125069] x1 : 0000000000000000 x0 : ffffffc011127004 [ 29.125077] Call trace: [ 29.125080] rt_spin_lock+0x54/0x90 [ 29.125088] update_bmc_sta+0xf4/0x140 [88XXau] [ 29.125192] rtw_start_bss_hdl_after_chbw_decided+0x5c/0x160 [88XXau] [ 29.125297] start_bss_network+0x1ec/0x8e0 [88XXau] [ 29.125402] createbss_hdl+0x28/0x140 [88XXau] [ 29.125507] rtw_cmd_thread+0x2f4/0x490 [88XXau] [ 29.125610] kthread+0x178/0x17c [ 29.125623] ret_from_fork+0x10/0x38 [ 29.125638] Code: d65f03c0 91006065 d2800001 f98000b1 (c85ffca0) [ 29.125645] ---[ end trace 0000000000000002 ]---
The following fixes have improved this problematic behavior. Hopefully, your consideration of this fix would be greatly appreciated.
--- ./core/rtw_sta_mgt.c_org 2023-05-02 10:07:11.000000000 +0900 +++ ./core/rtw_sta_mgt.c 2023-12-18 15:33:27.440527231 +0900 @@ -230,12 +230,16 @@ u32 _rtw_init_sta_priv(struct sta_priv * pstapriv->padapter = adapter; - pstapriv->pallocated_stainfo_buf = rtw_zvmalloc(sizeof(struct sta_info) * NUM_STA + 4); + pstapriv->pallocated_stainfo_buf = rtw_zvmalloc( + sizeof(struct sta_info) * NUM_STA + MEM_ALIGNMENT_OFFSET); if (!pstapriv->pallocated_stainfo_buf) goto exit; - pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf + 4 - - ((SIZE_PTR)(pstapriv->pallocated_stainfo_buf) & 3); + pstapriv->pstainfo_buf = pstapriv->pallocated_stainfo_buf; + if ((SIZE_PTR)pstapriv->pstainfo_buf & MEM_ALIGNMENT_PADDING) { + pstapriv->pstainfo_buf += MEM_ALIGNMENT_OFFSET - + ((SIZE_PTR)pstapriv->pstainfo_buf & MEM_ALIGNMENT_PADDING); + } _rtw_init_queue(&pstapriv->free_sta_queue); @@ -313,7 +317,8 @@ u32 _rtw_init_sta_priv(struct sta_priv * exit: if (ret != _SUCCESS) { if (pstapriv->pallocated_stainfo_buf) - rtw_vmfree(pstapriv->pallocated_stainfo_buf, sizeof(struct sta_info) * NUM_STA + 4); + rtw_vmfree(pstapriv->pallocated_stainfo_buf, + sizeof(struct sta_info) * NUM_STA + MEM_ALIGNMENT_OFFSET); #ifdef CONFIG_AP_MODE if (pstapriv->sta_aid) rtw_mfree(pstapriv->sta_aid, pstapriv->max_aid * sizeof(struct sta_info *)); @@ -460,7 +465,8 @@ u32 _rtw_free_sta_priv(struct sta_priv * #endif if (pstapriv->pallocated_stainfo_buf) - rtw_vmfree(pstapriv->pallocated_stainfo_buf, sizeof(struct sta_info) * NUM_STA + 4); + rtw_vmfree(pstapriv->pallocated_stainfo_buf, + sizeof(struct sta_info) * NUM_STA + MEM_ALIGNMENT_OFFSET); #ifdef CONFIG_AP_MODE if (pstapriv->sta_aid) rtw_mfree(pstapriv->sta_aid, pstapriv->max_aid * sizeof(struct sta_info *));```
Using the v5.6.4.2 driver, the following behavior was observed when CONFIG_PREEMPT_RT was enabled for the Linux kernel supporting the RT patch. The kernel version is 5.10.186-rt91 und rt patch applyed for 5.10.186.
The following fixes have improved this problematic behavior. Hopefully, your consideration of this fix would be greatly appreciated.