rtw88bu:rfe support needed #1

ulli-kroll · 2020-03-09T21:28:39Z

We have several antenna modes, for delta swing.
In upstream PCI driver is only one supported

rip out delta swing tables from rtl8822bu

…utex Remove circular lock dependency by using atomic version of interfaces iterate in watch_dog_work(), hence avoid taking local->iflist_mtx (rtw_vif_watch_dog_iter() only update some data, it can be called from atomic context). Fixes below LOCKDEP warning: [ 1157.219415] ====================================================== [ 1157.225772] [ INFO: possible circular locking dependency detected ] [ 1157.232150] 3.10.0-1043.el7.sgruszka1.x86_64.debug #1 Not tainted [ 1157.238346] ------------------------------------------------------- [ 1157.244635] kworker/u4:2/14490 is trying to acquire lock: [ 1157.250194] (&rtwdev->mutex){+.+.+.}, at: [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88] [ 1157.259151] but task is already holding lock: [ 1157.265085] (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211] [ 1157.276169] which lock already depends on the new lock. [ 1157.284488] the existing dependency chain (in reverse order) is: [ 1157.292101] -> #2 (&local->iflist_mtx){+.+...}: [ 1157.296919] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.302955] [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410 [ 1157.309416] [<ffffffffc0b6038f>] ieee80211_iterate_interfaces+0x2f/0x60 [mac80211] [ 1157.317730] [<ffffffffc09811ab>] rtw_watch_dog_work+0xcb/0x130 [rtw88] [ 1157.325003] [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720 [ 1157.331481] [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0 [ 1157.337589] [<ffffffffbc6e107f>] kthread+0xef/0x100 [ 1157.343260] [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39 [ 1157.350091] -> #1 ((&(&rtwdev->watch_dog_work)->work)){+.+...}: [ 1157.356314] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.362427] [<ffffffffbc6d570b>] flush_work+0x5b/0x310 [ 1157.368287] [<ffffffffbc6d740e>] __cancel_work_timer+0xae/0x170 [ 1157.374940] [<ffffffffbc6d7583>] cancel_delayed_work_sync+0x13/0x20 [ 1157.381930] [<ffffffffc0982b49>] rtw_core_stop+0x29/0x50 [rtw88] [ 1157.388679] [<ffffffffc098bee6>] rtw_enter_ips+0x16/0x20 [rtw88] [ 1157.395428] [<ffffffffc0983242>] rtw_ops_config+0x42/0x90 [rtw88] [ 1157.402173] [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211] [ 1157.409854] [<ffffffffc0b3925b>] ieee80211_do_open+0x69b/0x9c0 [mac80211] [ 1157.417418] [<ffffffffc0b395e9>] ieee80211_open+0x69/0x70 [mac80211] [ 1157.424496] [<ffffffffbcd03442>] __dev_open+0xe2/0x160 [ 1157.430356] [<ffffffffbcd03773>] __dev_change_flags+0xa3/0x180 [ 1157.436922] [<ffffffffbcd03879>] dev_change_flags+0x29/0x60 [ 1157.443224] [<ffffffffbcda14c4>] devinet_ioctl+0x794/0x890 [ 1157.449331] [<ffffffffbcda27b5>] inet_ioctl+0x75/0xa0 [ 1157.455087] [<ffffffffbccd54eb>] sock_do_ioctl+0x2b/0x60 [ 1157.461178] [<ffffffffbccd5753>] sock_ioctl+0x233/0x310 [ 1157.467109] [<ffffffffbc8bd820>] do_vfs_ioctl+0x410/0x6c0 [ 1157.473233] [<ffffffffbc8bdb71>] SyS_ioctl+0xa1/0xc0 [ 1157.478914] [<ffffffffbce84a5e>] system_call_fastpath+0x25/0x2a [ 1157.485569] -> #0 (&rtwdev->mutex){+.+.+.}: [ 1157.490022] [<ffffffffbc7409d1>] __lock_acquire+0xec1/0x1630 [ 1157.496305] [<ffffffffbc741a29>] lock_acquire+0x99/0x1e0 [ 1157.502413] [<ffffffffbce72793>] mutex_lock_nested+0x93/0x410 [ 1157.508890] [<ffffffffc098322b>] rtw_ops_config+0x2b/0x90 [rtw88] [ 1157.515724] [<ffffffffc0b13343>] ieee80211_hw_config+0xc3/0x680 [mac80211] [ 1157.523370] [<ffffffffc0b8a4ca>] ieee80211_recalc_ps.part.27+0x9a/0x180 [mac80211] [ 1157.531685] [<ffffffffc0b8abc5>] ieee80211_mgd_probe_ap.part.28+0x115/0x160 [mac80211] [ 1157.540353] [<ffffffffc0b8b40d>] ieee80211_beacon_connection_loss_work+0x4d/0x80 [mac80211] [ 1157.549513] [<ffffffffbc6d77bc>] process_one_work+0x22c/0x720 [ 1157.555886] [<ffffffffbc6d7dd6>] worker_thread+0x126/0x3b0 [ 1157.562170] [<ffffffffbc6e107f>] kthread+0xef/0x100 [ 1157.567765] [<ffffffffbce848b7>] ret_from_fork_nospec_end+0x0/0x39 [ 1157.574579] other info that might help us debug this: [ 1157.582788] Chain exists of: &rtwdev->mutex --> (&(&rtwdev->watch_dog_work)->work) --> &local->iflist_mtx [ 1157.593024] Possible unsafe locking scenario: [ 1157.599046] CPU0 CPU1 [ 1157.603653] ---- ---- [ 1157.608258] lock(&local->iflist_mtx); [ 1157.612180] lock((&(&rtwdev->watch_dog_work)->work)); [ 1157.620074] lock(&local->iflist_mtx); [ 1157.626555] lock(&rtwdev->mutex); [ 1157.630124] *** DEADLOCK *** [ 1157.636148] 4 locks held by kworker/u4:2/14490: [ 1157.640755] #0: (%s#6){.+.+.+}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720 [ 1157.648965] #1: ((&ifmgd->beacon_connection_loss_work)){+.+.+.}, at: [<ffffffffbc6d774a>] process_one_work+0x1ba/0x720 [ 1157.659950] #2: (&wdev->mtx){+.+.+.}, at: [<ffffffffc0b8aad5>] ieee80211_mgd_probe_ap.part.28+0x25/0x160 [mac80211] [ 1157.670901] #3: (&local->iflist_mtx){+.+...}, at: [<ffffffffc0b8ab7a>] ieee80211_mgd_probe_ap.part.28+0xca/0x160 [mac80211] [ 1157.682466] Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Testing with RTL8822BE hardware, when available memory is low, we frequently see a kernel panic and system freeze. First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed): rx routine starvation WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822 rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] [ 2356.580313] RIP: 0010:rtw_pci_rx_isr.constprop.25+0x35a/0x370 [rtwpci] Then we see a variety of different error conditions and kernel panics, such as this one (trimmed): rtw_pci 0000:02:00.0: pci bus timeout, check dma status skbuff: skb_over_panic: text:00000000091b6e66 len:415 put:415 head:00000000d2880c6f data:000000007a02b1ea tail:0x1df end:0xc0 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:105! invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:skb_panic+0x43/0x45 When skb allocation fails and the "rx routine starvation" is hit, the function returns immediately without updating the RX ring. At this point, the RX ring may continue referencing an old skb which was already handed off to ieee80211_rx_irqsafe(). When it comes to be used again, bad things happen. This patch allocates a new, data-sized skb first in RX ISR. After copying the data in, we pass it to the upper layers. However, if skb allocation fails, we effectively drop the frame. In both cases, the original, full size ring skb is reused. In addition, to fixing the kernel crash, the RX routine should now generally behave better under low memory conditions. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053 Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

In case of rtw8822be, a probe failure after successful rtw_core_init() has been observed to occasionally lead to an oops from rtw_load_firmware_cb(): [ 3.924268] pci 0001:01:00.0: [10ec:b822] type 00 class 0xff0000 [ 3.930531] pci 0001:01:00.0: reg 0x10: [io 0x0000-0x00ff] [ 3.936360] pci 0001:01:00.0: reg 0x18: [mem 0x00000000-0x0000ffff 64bit] [ 3.944042] pci 0001:01:00.0: supports D1 D2 [ 3.948438] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 3.957312] pci 0001:01:00.0: BAR 2: no space for [mem size 0x00010000 64bit] [ 3.964645] pci 0001:01:00.0: BAR 2: failed to assign [mem size 0x00010000 64bit] [ 3.972332] pci 0001:01:00.0: BAR 0: assigned [io 0x10000-0x100ff] [ 3.986240] rtw_8822be 0001:01:00.0: enabling device (0000 -> 0001) [ 3.992735] rtw_8822be 0001:01:00.0: failed to map pci memory [ 3.998638] rtw_8822be 0001:01:00.0: failed to request pci io region [ 4.005166] rtw_8822be 0001:01:00.0: failed to setup pci resources [ 4.011580] rtw_8822be: probe of 0001:01:00.0 failed with error -12 [ 4.018827] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 4.029121] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 4.050828] Unable to handle kernel paging request at virtual address edafeaac9607952c [ 4.058975] Mem abort info: [ 4.058980] ESR = 0x96000004 [ 4.058990] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.070353] SET = 0, FnV = 0 [ 4.073487] EA = 0, S1PTW = 0 [ 4.073501] dw-apb-uart 98007800.serial: forbid DMA for kernel console [ 4.076723] Data abort info: [ 4.086415] ISV = 0, ISS = 0x00000004 [ 4.087731] Freeing unused kernel memory: 1792K [ 4.090391] CM = 0, WnR = 0 [ 4.098091] [edafeaac9607952c] address between user and kernel address ranges [ 4.105418] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 4.111129] Modules linked in: [ 4.114275] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.9.0-rc5-next-20200915+ #700 [ 4.122386] Hardware name: Realtek Saola EVB (DT) [ 4.127223] Workqueue: events request_firmware_work_func [ 4.132676] pstate: 60000005 (nZCv daif -PAN -UAO BTYPE=--) [ 4.138393] pc : rtw_load_firmware_cb+0x54/0xbc [ 4.143040] lr : request_firmware_work_func+0x44/0xb4 [ 4.148217] sp : ffff800010133d70 [ 4.151616] x29: ffff800010133d70 x28: 0000000000000000 [ 4.157069] x27: 0000000000000000 x26: 0000000000000000 [ 4.162520] x25: 0000000000000000 x24: 0000000000000000 [ 4.167971] x23: ffff00007ac21908 x22: ffff00007ebb2100 [ 4.173424] x21: ffff00007ad35880 x20: edafeaac96079504 [ 4.178877] x19: ffff00007ad35870 x18: 0000000000000000 [ 4.184328] x17: 00000000000044d8 x16: 0000000000004310 [ 4.189780] x15: 0000000000000800 x14: 00000000ef006305 [ 4.195231] x13: ffffffff00000000 x12: ffffffffffffffff [ 4.200682] x11: 0000000000000020 x10: 0000000000000003 [ 4.206135] x9 : 0000000000000000 x8 : ffff00007e73f680 [ 4.211585] x7 : 0000000000000000 x6 : ffff80001119b588 [ 4.217036] x5 : ffff00007e649c80 x4 : ffff00007e649c80 [ 4.222487] x3 : ffff80001119b588 x2 : ffff8000108d1718 [ 4.227940] x1 : ffff800011bd5000 x0 : ffff00007ac21600 [ 4.233391] Call trace: [ 4.235906] rtw_load_firmware_cb+0x54/0xbc [ 4.240198] request_firmware_work_func+0x44/0xb4 [ 4.245027] process_one_work+0x178/0x1e4 [ 4.249142] worker_thread+0x1d0/0x268 [ 4.252989] kthread+0xe8/0xf8 [ 4.256127] ret_from_fork+0x10/0x18 [ 4.259800] Code: f94013f5 a8c37bfd d65f03c0 f9000260 (f9401681) [ 4.266049] ---[ end trace f822ebae1a8545c2 ]--- To avoid this, wait on the completion callbacks in rtw_core_deinit() before releasing firmware and continuing teardown. Note that rtw_wait_firmware_completion() was introduced with c8e5695eae9959fc5774c0f490f2450be8bad3de ("rtw88: load wowlan firmware if wowlan is supported"), so backports to earlier branches may need to inline wait_for_completion(&rtwdev->fw.completion) instead. Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Fixes: c8e5695eae99 ("rtw88: load wowlan firmware if wowlan is supported") Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200920132621.26468-2-afaerber@suse.de

karlp · 2021-06-07T16:21:38Z

Related, I have a new out of box rtl8821cu module that reports "rfe = 0xff" so this driver aborts. I've tried the https://github.com/morrownr/8821cu driver as well, and it allows overrriding with a manual figure, but no guidance on what to set it to. I've set it to "1" on this device and... well, it functions at least, not sure what's out of range now though :)

ulli-kroll · 2021-06-09T16:41:44Z

I assume RFE with RF endpoint aka power amplifier (PNA), low noise applifier (LNA) and antenna
you may void your regulations.

RFE with 0xff is mostly because unpopulated EEPROM values.

karlp · 2021-06-10T13:26:24Z

who's meant to be populating them, and how can I write to them? These are using pcb modules, so the antenna path is under our control, is there tooling to write eeprom values over usb?I still don't know what numbers should be used

ulli-kroll · 2021-06-17T14:32:40Z

Weird thing.
I have a working 8821cu device and also some "not working" 8821cu device.
Both have "filled" eeproms, but I need to check the offsets.
Also I have a working 8821ce device.
I'm preparing some branches for updates from master (vanilla linux) up to v5.13
and dumping the eeprom contents.

ulli-kroll · 2021-07-05T17:35:59Z

please checkout
rfe_eeprom_dump
branch

This will dump physical and logical layout of the eeprom
I need only the logical layout.
here some "example"

[  474.662370] rtw_8821cu 1-1.4:1.2: dump locial map
[  474.667086] 00000000: 29 81 00 bc 09 00 21 00 6e 04 a4 34 10 00 30 0b  ).....!.n..4..0.
[  474.675106] 00000010: 1f 20 21 21 21 21 27 28 29 29 29 ff ff ff ff ff  . !!!!'())).....
[  474.683120] 00000020: ff ff 27 26 26 26 26 26 25 25 24 24 22 24 24 24  ..'&&&&&%%$$"$$$
.. /* Here is the miracle */
[  474.795321] 00000100:

I need this from 0x000 until 0x0100
Also I left missing part intentional blank ;-)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rtw88bu:rfe support needed #1

rtw88bu:rfe support needed #1

ulli-kroll commented Mar 9, 2020

karlp commented Jun 7, 2021

ulli-kroll commented Jun 9, 2021

karlp commented Jun 10, 2021

ulli-kroll commented Jun 17, 2021

ulli-kroll commented Jul 5, 2021

rtw88bu:rfe support needed #1

rtw88bu:rfe support needed #1

Comments

ulli-kroll commented Mar 9, 2020

karlp commented Jun 7, 2021

ulli-kroll commented Jun 9, 2021

karlp commented Jun 10, 2021

ulli-kroll commented Jun 17, 2021

ulli-kroll commented Jul 5, 2021