Wifi does not work after Suspend. [DRIVER RTL8723BE]

I'm thinking there may be issues with the ethernet connection as well. If you aren't using your ethernet, I think we should try blacklisting r8169 to see what happens. We could also blacklist btusb, but one thing at a time.

To blacklist the r8169 driver enter the following command:

sudo echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist.conf

Tried that, didn't work !
Also tried blacklisting the btusb module.
Didn't work also.
I've been noticing things are starting to act hectic in this manjaro install, random horizontal lines popping up, bluetooth not working, and when i clicked the shutoff button i was prompted into a login screen that logged me back in, so i had to turn off the laptop by holding the power button until the machine switched off.
Guess I've been changing configs here and there and its starting to affect stuff ?

Anyways

Yeah, i'm starting to lose hope ...

maybe i'll try downgrading the kernel, but i dont think anything will work at this point tbh ...

:sweat:

Just read a thread on suspend issues that may resolve your problem, (if you have a similar cause).

I also read several posts suggesting this driver has problems with kernels 4.14 & 4.16. However, they said kernel 4.15 was working properly with your card. I did not suggest 4.15 as it is now designated EOL. Perhaps give kernel 4.15 a try.

I found this solution to your issue on the Arch forum. Enter command:

echo 1  | sudo tee /sys/bus/pci/rescan

That triggers a full rescan of the PCI bus after suspend, and may help fix your issue.

Okay, i will try out the two latest solutions ASAP !
Thank you.

1 Like

I'm an Ubuntu user and I've been facing this problem for nearly 2 years now.
I upgraded to Ubuntu 18.04 lately and instead of using suspend, I switched to using hibernate instead.
It's almost as fast as resuming from a suspend.

Also,
I just came across an article,
https://dirkmittler.homeip.net/blog/archives/1132?sm_au=iVVJ32k3Z403l4v3
that could be helpful, I'm not sure. You can give it a try. I'm not close to my laptop so I can't give it a try right now.

Hibernate is not a good option for an SSD drive, way to many write operations using suspend to disk. Suspending to disk is fine for platter drives though, so if he's on a spinner then that would be a good option.

Nice article thanks for the post.

1 Like

Yeah, it won't be good for a SSD. Thanks for pointing it out!

I don't have one so I don't mind putting it to hibernate. But hibernating still sucks, I would love to suspend it. Resuming from hibernation takes time and no matter how small it is, it's never less than waking up from suspend.

@zenAndroid Try what's written in the article I mentioned when you have time and let me know if it works or not, thanks :slight_smile:

2 Likes

Hi,
iam experiencing the same issue on a Surface Pro 1796. Or I was. Simply was typing in:
sudo systemctl stop NetworkManager
sudo systemctl start NetworkManager
w/o changing any scripts. Now it looks like I cannot replicate the problem any more. I will do some further testing but am not very good with systemd. Changing Kernels does not do it. I assume it is a simple setup problem. Maybe the socket. Close and open ur lid and see what happened with demsg. I am seeing a SIGSEV now but everythings seems to work fine. I use Manjaro 17.1.10 Kernel 4.16.8-1 with i3wm. Same happened with the 4.14 Kernel.

good luck

Edit: One more thing. I had trouble to connect to wifi after installation in the first place. I was repeatedly requested for the password and it did not want to connect. By creating a new wifi connection manually that was solved. You can do that by clicking on the wifi indicator and choose "Create new Wi-Fi Network". Just type in ur SSID and choose the right security option (usually WPA & WPA2 Personal) and give it the pass phrase. That should help a lot with debugging ur problem.

2 Likes

Wouldn't hurt to try kernel 4.17, if you haven't tried it yet.
Are you sure your adapter is rtl8723be.
Have you tested any of the suggested fixes on your card (if it is indeed an rtl8723be adapter).

Nope, does not help. When I close the lid on my Surface and open it again I can see the wifi indicator reconnect. When it was to sleep for too long it does not do anything anymore. dmesg shows then "reset in progress"

You still have not indicated if you are using the rtl8723be adapter, or which of the fixes suggested (aside from installing k4.17) you have tested. It's pretty hard to help someone who refuses to provide any information.

Sorry, was tired and went to bed.
The driver on the Surface Pro 1796 is mwifiex (marvel). Pls tell me the specific output you need. I meanwhile have found many commands to get the status of this hardware. The behavior is some how odd. After I thought I fixed it, the problem came back. Closing the lid and opening it again does not any harm the first time. I can see the connection reestablished and dmesg show a clean circle. After doing it a 2. or 3. or 4. time the connection is not comming back. dmesg shows me the the device is in status reset.
Here is the output of 'dmesg|tail -20' when the connection comes backup successfully:

[ 1091.626066] mwifiex_pcie 0000:01:00.0: None of the WOWLAN triggers enabled 
[ 1096.090829] OOM killer enabled. 
[ 1096.090830] Restarting tasks ... done. 
[ 1096.102098] PM: suspend exit 
[ 1096.107382] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready 
[ 1096.107444] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready 
[ 1096.153182] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready 
[ 1096.345340] usb 1-7: new full-speed USB device number 4 using xhci_hcd 
[ 1096.486732] usb 1-7: New USB device found, idVendor=045e, idProduct=09c0 
[ 1096.486737] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 
[ 1096.486741] usb 1-7: Product: Surface Type Cover 
[ 1096.486745] usb 1-7: Manufacturer: Microsoft 
[ 1096.494361] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input32 
[ 1096.549173] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input34 
[ 1096.549398] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0004/input/input36 
[ 1096.549823] hid-multitouch 0003:045E:09C0.0004: input,hiddev0,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0 
[ 1097.069478]  sda: sda1 
[ 1099.645108] mwifiex_pcie 0000:01:00.0: info: trying to associate to 'NACHTKAPP' bssid f8:35:dd:35:db:57 
[ 1099.667429] mwifiex_pcie 0000:01:00.0: info: associated to bssid f8:35:dd:35:db:57 successfully 
[ 1099.730737] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link becomes ready

next is when it fails (usually after the second sleep, meaning closing the lid):

[ 1167.288631] input: Microsoft Surface Type Cover Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0005/input/input51
[ 1167.344147] input: Microsoft Surface Type Cover Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0005/input/input53
[ 1167.344419] input: Microsoft Surface Type Cover Touchpad as /devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/0003:045E:09C0.0005/input/input55
[ 1167.344835] hid-multitouch 0003:045E:09C0.0005: input,hiddev0,hidraw0: USB HID v1.11 Keyboard [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input0
[ 1167.864193]  sda: sda1
[ 1168.267117] mwifiex_pcie 0000:01:00.0: Firmware wakeup failed
[ 1168.267693] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.275623] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.275690] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.275788] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.276120] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.276162] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.276270] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.277131] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.277954] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.308293] IPv6: ADDRCONF(NETDEV_UP): wlp1s0: link is not ready
[ 1168.309294] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1168.309298] mwifiex_pcie 0000:01:00.0: scan failed: -1
[ 1171.989912] mwifiex_pcie 0000:01:00.0: PREP_CMD: FW in reset state
[ 1171.989919] mwifiex_pcie 0000:01:00.0: scan failed: -1

The last line can be replicated by issuing 'iw dev wlp1s0 scan' which usually comes back with all the wifis in range. I have activatet debugfs. Here is the output of 'cat /debugfs/mwifiex/mlan0/info'

driver_name = "mwifiex"
driver_version = mwifiex 1.0 (15.68.7.p154) 
verext = w8897o-B0, RF87XX, FP68, 15.68.7.p154
interface_name="wlp1s0"
bss_mode="STATION"
media_state="Connected"
mac_address="c4:9d:ed:8f:3e:4f"
multicast_count="7"
essid="NACHTKAPP"
bssid="f8:35:dd:35:db:57"
channel="11"
country_code = "US"
region_code="0x10"
multicast_address[0]="01:00:5e:00:00:01"
multicast_address[1]="33:33:00:00:00:01"
multicast_address[2]="33:33:ff:e5:e9:d3"
multicast_address[3]="33:33:ff:69:0d:5b"
multicast_address[4]="33:33:ff:00:00:06"
multicast_address[5]="01:00:5e:00:00:fb"
multicast_address[6]="33:33:00:00:00:fb"
num_tx_bytes = 1094371
num_rx_bytes = 30498330
num_tx_pkts = 12079
num_rx_pkts = 21668
num_tx_pkts_dropped = 0
num_rx_pkts_dropped = 3277
num_tx_pkts_err = 0
num_rx_pkts_err = 0
carrier on
tx queue 0:started 1:started 2:started 3:started

and this after beeing stuck in reset state:

driver_name = "mwifiex"
driver_version = mwifiex 1.0 (15.68.7.p154) 
verext = w8897o-B0, RF87XX, FP68, 15.68.7.p154
interface_name="wlp1s0"
bss_mode="STATION"
media_state="Disconnected"
mac_address="c4:9d:ed:8f:3e:4f"
multicast_count="1"
essid=""
bssid="00:00:00:00:00:00"
channel="0"
country_code = "US"
region_code="0x10"
multicast_address[0]="01:00:5e:00:00:01"
num_tx_bytes = 1128292
num_rx_bytes = 30532576
num_tx_pkts = 12295
num_rx_pkts = 21818
num_tx_pkts_dropped = 0
num_rx_pkts_dropped = 3285
num_tx_pkts_err = 0
num_rx_pkts_err = 0
carrier off
tx queue 0:stopped 1:stopped 2:stopped 3:stopped

I also added this to the "/etc/NetworkManager/NetworkManager.conf"

# Configuration file for NetworkManager.
# See "man 5 NetworkManager.conf" for details.
[device-mac-randomization]
wifi.scan-rand-mac-address=no

[connection-mac-randomization]
ethernet.cloned-mac-address=permanent
wifi.cloned-mac-address=permanent

[connection]
wifi.powersave=2

I am new in this forum and hope iam doing this right here. Pls bare with me.

I apologize for the duplication, but you should really open your own help thread as you have totally different hardware and symptoms than the original post.

In your initial post you should list your HW info by posting the output of:

inxi -Fxzc0

If your issues were identical it would be fine to continue on this thread, but they are not. He has a total WiFi blockage after suspend, while yours is intermittent.

Please open your own help thread.

I did so.

thanks

I helped work this issue out on a related thread. Perhaps the solution there will help others searching to resolve this issue:

Here are the scripts I wrote to correct the WiFi breakage.

Part 1) WiFi module suspend scrpts:

Create a simple script to unload your network WiFi module before entering suspend. Substitute in your Wifi module where appropriate.

#!/bin/bash
modprobe -r 8812au

Save as /usr/bin/netmod-suspend.sh & make it executable and owned by root:

sudo chown root:root /usr/bin/netmod-suspend.sh
sudo chmod +x /usr/bin/netmod-suspend.sh

Create a systemd unit file with the following contents:

# cat netmod-suspend.service 
# /etc/systemd/system/netmod-suspend.service
[Unit]
Description=Network module suspend helper
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/netmod-suspend.sh

[Install]
WantedBy=sleep.target

Save it as /etc/systemd/system/netmod-suspend.service & make it executable and owned by root

sudo chown root:root /etc/systemd/system/netmod-suspend.service
sudo chmod +x /etc/systemd/system/netmod-suspend.service

Then:

sudo systemctl enable netmod-suspend.service
sudo systemctl start netmod-suspend.service

Part 2 contains the scripts to load your WiFi modules after resuming from suspend.

Part 2) WiFi module resume scripts:

Create a simple script to load your network WiFi module after resuming from suspend. Substitute in your Wif module where appropriate.

#!/bin/bash
modprobe 8812au

Save as /usr/bin/netmod-resume.sh & make it executable and owned by root
sudo chown root:root /usr/bin/netmod-resume.sh
sudo chmod +x /usr/bin/netmod-resume.sh

Create a systemd unit file with the following contents:

# systemctl cat netmod-resume.service
# /etc/systemd/system/netmod-resume.service

[Unit]
Description=Network module resume helper
After=suspend.target

[Service]
Type=simple
ExecStart=-/usr/bin/netmod-resume.sh

[Install]
WantedBy=suspend.target

Save it as /etc/systemd/system/netmod-resume.service & make it executable and owned by root.

sudo chown root:root /etc/systemd/system/netmod-resume.service
sudo chmod +x /etc/systemd/system/netmod-resume.service

Then:

sudo systemctl enable netmod-resume.service
sudo systemctl start netmod-resume.service

Part 1 + Part 2 are complete working suspend and resume WiFi service scripts.

Hmm, sorry for taking so long to get back to you @tbg
I tried the earlier fixes and they didn't work but the issue here is that, since this install got REALLY unstable (only way to leave the computer is to hold the power off button, which is something i hate to have to do, horizontal lines showing up randomly when redrawing the screen, screen brightness keys not working, etc) i dont know if the issue with the fix or with the config files i modified)
maybe they had some unexpected side-effects ?
maybe i unintentionnally edited the wrong ones ? (highly doubt this)
So yeah, i think i'll have to format the partition and reinstall, but i think i'll wait a while.

After the clean reinstall maybe i'll check out these two last posts you made.

Thanks, and sorry for being lazy and not immediately reinstalling :confused:

Guys, I finally found a solution. And it's gonna work for sure but it also involves a little money. A USB wireless adaptor costed me around 500 INR on Amazon. I bought it, installed the drivers from github, but suspend still had an issue.
Then I decided to reset my BIOS settings to default. So, when you reset it to default settings, it turns on secure boot. Since secure boot is on, RTL8723BE doesn't function, it disappeared from the menu when I booted up my system. I connected to my WiFi using the USB adaptor and then suspended the system. Woke it back up and the wifi was still working!
I couldn't have been happier. I hope this helps!!!!! :smiley:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by