Samuel Reyes <zohrlaffz@xxxxxxxxx> wrote: > On Wed, May 7, 2025 at 7:23 PM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote: > > > > Samuel Reyes <zohrlaffz@xxxxxxxxx> wrote: > > > On Mon, May 5, 2025 at 8:11 PM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote: > > > > > > > > Samuel Reyes <zohrlaffz@xxxxxxxxx> wrote: > > > > > Big update, I updated my motherboard to the newest BIOS (vF4) and it > > > > > has helped dramatically with the amount of errors in dmesg. But the > > > > > issue with the connection dropping after some time remains. I added > > > > > amd_iommu=off to my kernel parameters and ran sudo iw wlan0 set > > > > > power_save off. I did NOT apply the kernel patch you included yet. I > > > > > ran dmesg when my connection dropped and saw a bunch of 'failed to > > > > > update XX RXBD info: -11' errors again. > > > > > > > > I don't have clear idea now. Please try my patch first. > > > > I will check internally and will need your help to collect more data. > > > > > > > > > > > > > > I managed to capture the connection drop in a recording so you can see > > > > > what it looks like on my end. My connection will remain 'broken' > > > > > indefinitely until I toggle airplane mode. > > > > > > > > > > Video: https://youtu.be/BbVlTU8K9Hg > > > > > > > > > > > > > Can you open a terminal to show kernel log next time? I would like to > > > > know disconnection happens along 'failed to update XX RXBD info: -11'. > > > > > > > > By the way, please not top-posting in wireless mailing. > > > > > > > > > > Hi! > > > > > > Thanks again for your assistance. > > > > > > I spent all day yesterday and this morning trying to figure out how to > > > apply your patch and wasn't able to do it. I'm by no means an expert > > > and quickly found that patching a kernel is no easy feat. > > > > What are the problems you met? Below is the rough steps to build driver: > > 1. grab kernel source > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git > > 2. switch to tag you are using > > eg. git checkout v6.14.2 > > 3. install toolchain/kernel header by 'apt install' > > sudo apt install build-essential > > (I don't remember how to install kernel header. Please google it yourself.) > > 4. make driver > > e.g. make -C /lib/modules/6.14.2-061402-generic/build > M=/$(KERNEL_SOURCE_PATH)/drivers/net/wireless/realtek/rtw89/ > > 5. rmmod/insmod > > ```lsmod | grep rtw89``` can see all rtw89 modules > > > > > > > I wanted to > > > record a before and after video (before your patch and after) of the > > > download, but since I couldn't figure out how to patch my kernel I > > > only have a before video. It has the terminal running so you can see > > > the errors pop up in real time. It's pretty long since I recorded it > > > from the very start of the download. The crash happens at around 11:30 > > > into the video: https://youtu.be/2nrLOuY6Pwk > > > > I guess the cause is that RXD can't be recognized and then > > "failed to release TX skbs" can't free TX WD properly, so run out of > > TX resource. Therefore, let's try the patch to see if we can resolve > > 'failed to update XX RXBD info: -11' problem first. > > > > > > > > P.S. I hope this is what you meant about top-posting, I also had to > > > research what that meant and how to avoid it :P > > > > Yes, it is. :) > > > > The obstacle was unloading the module which was in use to load in the > patched one. I did it though, I had to boot from an Arch live > environment on a USB. That will be easier after this success. :) > > Anyways the patch works!! dmesg is clear of those pesky RXBD messages > and my download completed without failure. This is the first time I've > been able to make a large download like that without the connection > dropping :) Good to hear the good news. I will make a patch for it. > > You'll see the download speed dip a few times (e.g. around 4:45 > minutes in the video) over the course of the download, but it always > recovers successfully. In the past those dips were a sign of the > connection dropping. > For me, these dips seems to be acceptable. If you want to dig further, I should check PHY rate first via debugfs: cd /sys/kernel/debug/ieee80211/phy0/rtw89 watch cat phy_info And, capture video as before. I admit this is only first step to see if the symptom is caused by PHY rate. If yes, I need air sniffer to know how it happens. If not, maybe system enters power save mode or others.
