lwfinger / rtw8852be

Linux driver for RTW8852BE PCIe card

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

WiFi not working on restart

opened this issue · comments

Hello,

Last night I updated to the latest version of this driver and installed it on Kernel 5.19.7 on Fedora 36. I'm now experiencing a bug where WiFi no longer auto-connects after restart. When investigating this, the settings panel tells me my adapter is searching for connectors, until eventually showing me no available results:
Screenshot from 2022-09-09 09-05-00
If I turn off the WiFi adapter (the toggle in the top-right corner in the above image) and turn it back on again, the WiFi connects and works perfectly. Yet, the next time I restart, it stops working, and I have to do the same thing again.

I'm not sure what could be causing the problem, but here's the appropriate lines from dmesg:

[   22.280319] NET: Registered PF_QIPCRTR protocol family
[   22.567399] 8852be: loading out-of-tree module taints kernel.
[   22.813550] rtl8852be 0000:01:00.0: enabling device (0000 -> 0003)
[   23.109597] eric-tx CALL alloc_txring !!!!
[   23.120325] rtl8852be 0000:01:00.0 wlp1s0: renamed from wlan0

Thanks for any help you can offer

Is this new behavior with kernel 5.19.7. The only change I made in the driver was to fix some array overruns and turn off debugging, which was just spamming the logs.

Your dmesg output is normal.

Is this a cold restart where the power was off. or a warm reboot? My system always does a 1 sec power-off before restarting so I cannot test a warm reboot.

This happens any time I start up the system - either a restart or from a power-off state.

I'm scouring the system logs for anything relevant, and I found this, unsure if it means anything:

<info>  [1662802887.7029] device (wlp1s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
<info>  [1662802887.6983] rfkill3: found Wi-Fi radio killswitch (at /sys/devices/pci0000:00/0000:00:02.2/0000:01:00.0/ieee80211/phy0/rfkill3) (driver rtl8852be)
<info>  [1662802887.6966] device (wlan0): interface index 2 renamed iface from 'wlan0' to 'wlp1s0'

Otherwise, I'm not exactly sure what to do. It's inconvenient, but not exactly system-breaking.

I've done a little more testing on my own - after I switched back to 5.19.6, with the slightly older driver version, WiFi connected instantly. After I upgraded to the newest driver on that same kernel, I began to experience this bug again. I have also installed this driver on 5.19.8, and am experiencing the same bug. I've made sure it's not my VPN - even after I fully uninstalled it, the bug remained.

This means that either a) some change made in the past week to this driver has caused this bug (I installed the slightly older, working version of the driver around last Sunday) or b) some change to a piece of software other than the kernel (e.g. NetworkManager) has caused this bug. The only package related to networking I upgraded in this period was nmap-ncat to version 3:7.93-1

If you think that this repo caused the problem, do a bisection. Keep in mind that it works for me.

I had a similar issue recently where no wireless networks were detected after a reboot/cold boot. This also happened to me after a system update, perhaps something has changed.

I can get it temporarily fix (until the next reboot) by telling iwconfig to used 2.5GHz instead of 5GHz and then going back to the default of 5GHz. Turning the adapter off and on again also fixes it.

Hello,

Last night I updated to the latest version of this driver and installed it on Kernel 5.19.7 on Fedora 36. I'm now experiencing a bug where WiFi no longer auto-connects after restart. When investigating this, the settings panel tells me my adapter is searching for connectors, until eventually showing me no available results: Screenshot from 2022-09-09 09-05-00 If I turn off the WiFi adapter (the toggle in the top-right corner in the above image) and turn it back on again, the WiFi connects and works perfectly. Yet, the next time I restart, it stops working, and I have to do the same thing again.

I'm not sure what could be causing the problem, but here's the appropriate lines from dmesg:

[   22.280319] NET: Registered PF_QIPCRTR protocol family
[   22.567399] 8852be: loading out-of-tree module taints kernel.
[   22.813550] rtl8852be 0000:01:00.0: enabling device (0000 -> 0003)
[   23.109597] eric-tx CALL alloc_txring !!!!
[   23.120325] rtl8852be 0000:01:00.0 wlp1s0: renamed from wlan0

Thanks for any help you can offer

My wi-fi works after disabling and enabling wi-fi, but it's very, very slow.

Can somebody please tell me how to revert to the version before the latest one?

Also, when I enable wi-fi, all audio (online and offline) starts cracking a little, but ONLY while using bluetooth.

I have now reverted to an earlier version of the driver (commit 184e277 specifically) and the problem has been resolved on my system.

Can somebody please tell me how to revert to the version before the latest one?

I don't have much experience with git, but my method for doing this was to cd into the driver's directory and checkout the commit I wanted:
git checkout 184e277
and then switching over to that branch, giving it the name 'older_version':
git switch -c older_version
Then just uninstall the current driver:
sudo make uninstall
then reboot and install the driver again.

My wi-fi works after disabling and enabling wi-fi, but it's very, very slow.

I had no issues with WiFi after restarting my adapter.

Also, when I enable wi-fi, all audio (online and offline) starts cracking a little, but ONLY while using bluetooth.

I don't use the bluetooth on my laptop, but make sure you've installed this driver.

If you think that this repo caused the problem, do a bisection. Keep in mind that it works for me.

Have you tested this on a Fedora install? My experience indicates it is the the commits made to this driver in the past week that cause this problem. @nestlecrunchkid @mauricioquintela what OS and kernel version (uname -r) are you folks using?

Have you tested this on a Fedora install? My experience indicates it is the the commits made to this driver in the past week that cause this problem. @nestlecrunchkid @mauricioquintela what OS and kernel version (uname -r) are you folks using?

OS: Fedora Linux 36 (KDE Plasma) x86_64
Host: HP Pavilion Laptop 15-eh2xxx
Kernel: 5.19.8-200.fc36.x86_64

Can somebody please tell me how to revert to the version before the latest one?

OK, I do not consider it my job to teach anyone how to use git!!!! There are lots of manuals on how to do that.

Have you tested this on a Fedora install? My experience indicates it is the the commits made to this driver in the past week that cause this problem. @nestlecrunchkid @mauricioquintela what OS and kernel version (uname -r) are you folks using?

Im currently running arch 5.19.7. Not really able to test speed because I'm currently being forced to use a dumb setup with usb tethering to have internet. Still, I will give 184e277 test to see if anything regarding "having to turn off and on again". WIll also implement ac14ca4 to silence the debug messages and the changes in phl/hal_g6/mac/mac_ax/dbg_cmd.c regarding shutting up the logs

I just forced an update. Please do a pull and tell me if it is working.

Did you do a massive clear of the commits, @lwfinger? Everything after you copied HRex39's version to master is gone, including returning to your original codebase

The update has fixed the problem for me. Thanks.

That version is flawed. Do another 'git pull' and try again.

Did you do a massive clear of the commits, @lwfinger? Everything after you copied HRex39's version to master is gone, including returning to your original codebase

Yes, I fouled up the repo and started over. The current state has my original code restored, and is doing very little log spamming. It is working here.

Works after the update. Thanks.

Did you do a massive clear of the commits, @lwfinger? Everything after you copied HRex39's version to master is gone, including returning to your original codebase

Yes, I fouled up the repo and started over. The current state has my original code restored, and is doing very little log spamming. It is working here.

Working fine here as well, no longer have to disable and re-enable on boot.

@lwfinger There's no rule to target sign-install anymore.

OOps. There is now.

With the problem resolved, I'll close this issue. Thanks again for all your hard work on this driver and others.

Reopening as problem has returned on latest version. The commits to fix KASAN errors are causing the issue (most recently 64eb705), as that's the only new commit since the problem was fixed.

Not only is WiFi not connecting on startup, but it is now significantly slower than usual and intermittent (disconnects occasionally).

@Bananeqqq is having a similar problem here, and I can only assume @saikatm is experiencing a similar issue here

Have just confirmed it is not the latest kernel update causing the problem - I was able to verify:
a) the latest version of the driver has the same issues on my previous kernel (5.19.8)
b) the version of the driver before the latest commit works perfectly on the latest kernel available on Fedora (5.19.9)

Have tested both KASAN commits and cd1356c, can confirm commit 64eb705 makes wifi have issues at start and is causing intermittent disconnects. Have not been able to notice anything regarding speed as I'm currently using a very slow connection.
Reverting to cd1356c fixes these issues,

OK, I will revert that change.

fixed #27

The update has fixed the problem for me - closing issue.