Hi there, i upgraded my Archlinux testing setup from 6.10.9 to 6.11 and noticed that my wifi is no longer working. Here is the output from the working 6.10.x Kernel 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller Subsystem: AzureWave Device 5470 Kernel driver in use: rtw89_8852be Kernel modules: rtw89_8852be On 6.11, loading the Kernel Module fails. After veryfing it is not an Archlinux issue by manually building the Kernel from kernel.org manually, i can verify, it happens with an vanilla Kernel too. Here are the relevant parts from dmesg [...] [ 4.687462] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 4.687472] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 4.687477] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 4.687486] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687501] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687516] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3b [ 4.687531] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687546] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3f [ 4.687561] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687576] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 4.687591] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687606] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4f [ 4.687621] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687636] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 4.687651] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687666] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f37 [ 4.687681] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 4.687696] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 6.376153] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 6.376163] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 6.376168] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 6.376178] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 6.376193] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f43 [ 6.376208] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 6.376223] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f41 [ 6.376238] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3f [ 6.376253] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376268] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376283] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 6.376298] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 6.376313] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376327] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376342] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 6.376357] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 6.376372] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 6.376387] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 7.135332] r8169 0000:05:00.0 enp5s0: Link is Up - 1Gbps/Full - flow control off [ 8.097173] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 8.097183] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 8.097188] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 8.097197] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 8.097212] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 8.097227] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097242] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f2f [ 8.097257] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 8.097272] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097287] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097302] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f31 [ 8.097317] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097332] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097347] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdb [ 8.097362] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f33 [ 8.097377] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097391] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 8.097406] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdb [ 9.817051] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 9.817059] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 9.817063] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 9.817072] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817087] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817102] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 9.817117] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccdf [ 9.817133] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccf7 [ 9.817147] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f3d [ 9.817162] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 9.817177] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817192] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817207] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 9.817222] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f55 [ 9.817237] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f53 [ 9.817252] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 9.817267] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 9.817282] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536604] rtw89_8852be 0000:04:00.0: [ERR]FWDL path ready [ 11.536615] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x1E0 = 0x23 [ 11.536621] rtw89_8852be 0000:04:00.0: [ERR]fwdl 0x83F0 = 0x70000 [ 11.536632] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 11.536648] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f55 [ 11.536664] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890cce1 [ 11.536680] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f7f [ 11.536697] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536713] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890cce3 [ 11.536730] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f31 [ 11.536746] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536762] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f4b [ 11.536778] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f35 [ 11.536794] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 11.536809] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536825] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f47 [ 11.536842] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb8901f57 [ 11.536859] rtw89_8852be 0000:04:00.0: [ERR]fw PC = 0xb890ccd9 [ 11.536874] rtw89_8852be 0000:04:00.0: failed to setup chip information [ 11.537455] rtw89_8852be 0000:04:00.0: probe with driver rtw89_8852be failed with error -110 [...] The whole dmesg can be found here (with an Download button on the top right): https://ignaz.org/nextcloud/index.php/s/gMtZCxS5wjtWSYc Best Regards Marcel #regzbot introduced: v6.10.9..v6.11
Marcel Weißenbach mweissenbach@ignaz.org wrote:
Hi there,
i upgraded my Archlinux testing setup from 6.10.9 to 6.11 and noticed that my wifi is no longer working.
Checking the commits between 6.10.9 and 6.11, I feel the cause is 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address")
Seemingly there is 36-bit PCI DMA interoperability on RTL8852BE. Could you please try below to comment out the function?
diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c index 02afeb3acce4..039fc329c6f7 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -3061,7 +3061,7 @@ static int rtw89_pci_setup_mapping(struct rtw89_dev *rtwdev, goto err; }
- ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(36)); + ret = -1;//dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(36)); if (!ret) { rtwpci->enable_dac = true; rtw89_pci_cfg_dac(rtwdev);
If this helps, please provide your DMI info by 'sudo dmidecode'. I will build a quirk table for it since I don't know what the exact settings affect this.
Setting ret to -1 did the job, wifi works again as expected. Here is the output of dmidecode https://ignaz.org/nextcloud/index.php/s/tZdjYYdyeWpHPH4 Thanks a lot "Ping-Ke Shih" pkshih@realtek.com – 2024年9月18日 15:02
Marcel Weißenbach mweissenbach@ignaz.org wrote:
Hi there, i upgraded my Archlinux testing setup from 6.10.9 to 6.11 and noticed that my wifi is no longer working.
Checking the commits between 6.10.9 and 6.11, I feel the cause is 1fd4b3fe52ef ("wifi: rtw89: pci: support 36-bit PCI DMA address") Seemingly there is 36-bit PCI DMA interoperability on RTL8852BE. Could you please try below to comment out the function? diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c index 02afeb3acce4..039fc329c6f7 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -3061,7 +3061,7 @@ static int rtw89_pci_setup_mapping(struct rtw89_dev *rtwdev, goto err; }
- ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(36));
- ret = -1;//dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(36));
if (!ret) { rtwpci->enable_dac = true; rtw89_pci_cfg_dac(rtwdev); If this helps, please provide your DMI info by 'sudo dmidecode'. I will build a quirk table for it since I don't know what the exact settings affect this.
Marcel Weißenbach mweissenbach@ignaz.org wrote:
Setting ret to -1 did the job, wifi works again as expected.
Here is the output of dmidecode https://ignaz.org/nextcloud/index.php/s/tZdjYYdyeWpHPH4
I wrote a quirk according to your dmidecode [1]. Please try if this can still work to you. If yes, please help to reply a Tested-by tag there. Thanks.
[1] https://lore.kernel.org/linux-wireless/20240918085551.54611-1-pkshih@realtek...
First of all, thank you so much for your time and work! I hope i don't cause any confusion and this question may be based on my lack of understanding the patch, i almost don't dare to ask, but does this quirk only gets into affect, when someone uses the same mainboard i use? Is this an rather rare case that probably won't effect other people? I can't judge that so please don't get me wrong, but i feel a bit uneasy about this. I assume that most fist time Linux users that have similar (but not the same) platform, where this quirk will not get applied and they end up with non-working wifi, just notice that wifi doesn't work and give up on Linux and remember it as "My Wifi even didn't work there". As a long time Gentoo user, i have the capability to build my own kernel and provide feedback that can help fix this issue, but i assume most users don't. I would assume an Ubuntu users will just remove the Ubuntu partition and calls it a day continuing using Windows. I am a bit worried and wonder, if there maybe a way to fix that, that is independent on my specific hardware/mainboard. Of course, feel free to correct me if i am getting something wrong here, im neither an Kernel nor C expert and thank you for your time again. "Ping-Ke Shih" pkshih@realtek.com – 2024年9月18日 18:00
Marcel Weißenbach mweissenbach@ignaz.org wrote:
Setting ret to -1 did the job, wifi works again as expected. Here is the output of dmidecode https://ignaz.org/nextcloud/index.php/s/tZdjYYdyeWpHPH4
I wrote a quirk according to your dmidecode [1]. Please try if this can still work to you. If yes, please help to reply a Tested-by tag there. Thanks. [1] https://lore.kernel.org/linux-wireless/20240918085551.54611-1-pkshih@realtek...
Marcel Weißenbach mweissenbach@ignaz.org wrote:
First of all, thank you so much for your time and work!
I hope i don't cause any confusion and this question may be based on my lack of understanding the patch, i almost don't dare to ask, but does this quirk only gets into affect, when someone uses the same mainboard i use? Is this an rather rare case that probably won't effect other people?
I can't judge that so please don't get me wrong, but i feel a bit uneasy about this. I assume that most fist time Linux users that have similar (but not the same) platform, where this quirk will not get applied and they end up with non-working wifi, just notice that wifi doesn't work and give up on Linux and remember it as "My Wifi even didn't work there".
As a long time Gentoo user, i have the capability to build my own kernel and provide feedback that can help fix this issue, but i assume most users don't. I would assume an Ubuntu users will just remove the Ubuntu partition and calls it a day continuing using Windows. I am a bit worried and wonder, if there maybe a way to fix that, that is independent on my specific hardware/mainboard.
Of course, feel free to correct me if i am getting something wrong here, im neither an Kernel nor C expert and thank you for your time again.
You are right. I was not aware of that. I will discuss people internally and reconsider the solution.
Ping-Ke Shih wrote:
Marcel Weißenbach mweissenbach@ignaz.org wrote:
First of all, thank you so much for your time and work!
I hope i don't cause any confusion and this question may be based on my lack of understanding the patch, i almost don't dare to ask, but does this quirk only gets into affect, when someone uses the same mainboard i use? Is this an rather rare case that probably won't effect other people?
I can't judge that so please don't get me wrong, but i feel a bit uneasy about this. I assume that most fist time Linux users that have similar (but not the same) platform, where this quirk will not get applied and they end up with non-working wifi, just notice that wifi doesn't work and give up on Linux and remember it as "My Wifi even didn't work there".
As a long time Gentoo user, i have the capability to build my own kernel and provide feedback that can
help
fix this issue, but i assume most users don't. I would assume an Ubuntu users will just remove the Ubuntu partition and calls it a day continuing using Windows. I am a bit worried and wonder, if there maybe a
way
to fix that, that is independent on my specific hardware/mainboard.
Of course, feel free to correct me if i am getting something wrong here, im neither an Kernel nor C expert and thank you for your time again.
You are right. I was not aware of that. I will discuss people internally and reconsider the solution.
With internal discussion, the early chips including RTL8852BE have interoperability problem with some platforms, so we decide to rollback to 32-bit DMA for these chips, and only enable 36-bit DMA for tested platforms.
Please help to test if [1] works to you.
[1] https://lore.kernel.org/linux-wireless/20240924021633.19861-1-pkshih@realtek...
Works as expected, thank you very much =) "Ping-Ke Shih" pkshih@realtek.com – 2024年9月24日 11:29
Ping-Ke Shih wrote:
Marcel Weißenbach mweissenbach@ignaz.org wrote:
First of all, thank you so much for your time and work!
I hope i don't cause any confusion and this question may be based on my lack of understanding the patch, i almost don't dare to ask, but does this quirk only gets into affect, when someone uses the same mainboard i use? Is this an rather rare case that probably won't effect other people?
I can't judge that so please don't get me wrong, but i feel a bit uneasy about this. I assume that most fist time Linux users that have similar (but not the same) platform, where this quirk will not get applied and they end up with non-working wifi, just notice that wifi doesn't work and give up on Linux and remember it as "My Wifi even didn't work there".
As a long time Gentoo user, i have the capability to build my own kernel and provide feedback that can
help
fix this issue, but i assume most users don't. I would assume an Ubuntu users will just remove the Ubuntu partition and calls it a day continuing using Windows. I am a bit worried and wonder, if there maybe a
way
to fix that, that is independent on my specific hardware/mainboard.
Of course, feel free to correct me if i am getting something wrong here, im neither an Kernel nor C expert and thank you for your time again.
You are right. I was not aware of that. I will discuss people internally and reconsider the solution.
With internal discussion, the early chips including RTL8852BE have interoperability problem with some platforms, so we decide to rollback to 32-bit DMA for these chips, and only enable 36-bit DMA for tested platforms. Please help to test if [1] works to you. [1] https://lore.kernel.org/linux-wireless/20240924021633.19861-1-pkshih@realtek...
linux-stable-mirror@lists.linaro.org
-
Marcel Weißenbach -
Ping-Ke Shih