For bluetooth: test the real time kernels
For wired LAN suspend issues:
For bluetooth: test the real time kernels
For wired LAN suspend issues:
the MX series cards so far have not needed an acpi call to be powered down but thats not the only thing that doesnt make sense.
after waking from suspend, the nvidia gpu should still not be visible, and even if sysfs rescans for devices there is a service that runs the no-optimus script after waking from suspend.
sudo nano /etc/mkinitcpio.conf
find/edit this line
sudo mkinitcpio -P
thats actually copy/paste from my mkinitcpio.conf
Yep, I will
Wow, never did system service before... I will have to dig a bit for a "howto".
And thank you for showing me the possible solution.
As I dont know so much about how linux works, I'm wondering if this network issues will be solved in the next update, then what about the 2 NetworkManager scripts ? Will have to remove or disable it manually ?
Thank you for helping me again!
Yes, it was working fine before the last update, and the Nvidia GPU was not visible in Intel mode
Well, it's not working, reboot twice and verify the modification done on file mkinitcpio.conf. I do not need to input my pwd.
I try first closing the lid (no change) and then with the suspend key (w/ moon icon). And with the suspend key, I was surprise that even if the led was blinking as it does in normal sleep, I was able to resume from suspend by pressing the return keyboard key. That's mean the sleeping process was NOT really on, as far as I know. Will have to look closer for real computer sleep method.
Just checking Powertop, it still show up Nvidia à 100%, always in Intel mode
Don't know what to do next
Maybe some install broke something ? I installed Virtualbox before the Manjaro update.
I made a (small) mistake installing cuda for dev before Manjaro update, and I had to download around 3 Go when updating. After the update, I remove cuda for dev with pamac.
To be complete I also installed intel-media-driver, is it conflicting with libva-intel-driver ?
Don't know if this will help
i think it's more probable to assume that it's a GDM issue and not a situation where suspend doesnt work. i would read logs and gdm output before/after suspend. give these a read and see if you find what your looking for.
also, when your trying different kernels for the networking issue, also test the gpu/suspend issue on each kernel and see if the unwanted behavior goes away.
also also, when something stops working with gdm/gnome, always start by disabling any/all extensions before doing anything else, and reset gdm to it's original configuration.
Your problem can usually be fixed with a single service file for suspend and resume. The service below will likely fix your suspend issue:
It is generally better to use the r8169 kernel driver rather than the r8168 driver. You can easily switch to the r8169 kernel driver with this command:
sudo mhwd -r pci network-r8168
After switching to the r8169 driver, if you are still experiencing issues you can create a service to hopefully resolve suspend problems related to your adapter.
Network Restart Service
Create the following file with a root capable text editor:
Add the following contents to the file:
#/etc/systemd/system/network-restart.service #sudo systemctl enable network-restart.service #sudo systemctl start network-restart.service #sudo systemctl stop network-restart.service #sudo systemctl disable network-restart.service #systemctl status network-restart.service [Unit] Description=Network Suspend/Resume Service Before=sleep.target StopWhenUnneeded=yes [Service] User=root Type=oneshot RemainAfterExit=yes ExecStartPre=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking off' ExecStart=/usr/bin/sleep 1 ExecStart=-/usr/bin/systemctl stop NetworkManager ExecStart=/usr/bin/sleep 1 ExecStart=-/usr/bin/ip link set enp2s0 down ExecStart=/usr/bin/sleep 1 ExecStart=-/usr/bin/modprobe -r r8169 ExecStop=-/usr/bin/modprobe r8169 ExecStop=/usr/bin/sleep 2 ExecStop=-/usr/bin/ip link set enp2s0 up ExecStop=/usr/bin/sleep 2 ExecStop=-/usr/bin/systemctl start NetworkManager ExecStop=/usr/bin/sleep 1 ExecStop=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking on' [Install] WantedBy=sleep.target
The sleep units in the service may be reduced, (or eliminated) if you do not like the delay it creates. Be aware though, that doing so may reduce the reliability of the service.
Once you have created and saved the service file, enable the service:
sudo systemctl enable network-restart.service
Then reboot the computer.
For others wishing to adapt this service to their installation (if different than above).
If your adapter's designation is different than “enp2s0” you will need to substitute you own adapter’s ID into the service file.
If you are using a different driver module you will also need to substitute it in place of “r8168” or “r8169”in the service file.
R8169 is the currently the recommended driver for this adapter. The r8168 driver should generally be uninstalled through Manjaro Settings Manger or the terminal command given above. I would highly suggest switching to the r8169 kernel module rather than using the r8168 driver.You can substitute "r8168" or "r8169" in the above service file depending on which driver you are using.
You can find your adapter driver/module and device ID to substitute in the service with the following command:
Alternate methods to switch to the r8169 driver:
The r8168 driver has been experiencing major problems lately.
The r8169 kernel module is now the preferred driver.
Follow the instructions below to get your LAN adapter working properly.
Uninstall the linuxXXX-r8168 driver:
Open Manjaro Settings Manager -> Hardware configuration -> Network controller
Right click on the RTL8111/8168/8411 ethernet device and select “Remove”.
After the uninstall process has finished, restart.
After you restart the computer, the 8169 kernel module should now be automatically loaded.
If the r8169 kernel module is not loaded automatically when you reboot (after uninstalling r8168) then do this:
Open any file located in
/etc/modprobe.d and ensure there is no reference to r8169.
Any file that contains the line:
Save the edited conf file with root permissions, and then reboot
Alternately, you may delete the conf file entirely, (if it only contains the entry "blacklist r8169").
/etc/modprobe.d contains a file named
r8169_blacklist.conf then you can delete it with this command:
sudo rm /etc/modprobe.d/r8169_blacklist.conf
Be very careful, you do not make any errors when using the "rm" command with sudo privileges.
Reboot after making any changes to files in
Pretty brilliant explanations for my poor knowledge. Thank you !
I will do it as soon as possible, but to be sure of what I've got so far, is there typo in this sentence ?
I understand as : r8168 is an old fashion driver ; r8169 is brand new (automatic) kernel module.
Hope you say yes
Already found the '8169_blacklist.conf' file...
[philippe@Probook-450 ~]$ inxi -n Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8168 IF: enp2s0 state: down mac: <filter> Device-2: Intel Wireless 8265 / 8275 driver: iwlwifi IF: wlp3s0 state: up mac: <filter> [philippe@Probook-450 ~]$
Yes, sorry I missed that typo. I edited it to be more clear.
Yes, you have the general gist of it. The kernel module will load automatically as long as it is not blacklisted.
You may find using the r8169 kernel module that your suspend issue goes away. If the driver switch fixes your suspend problem then there is no need to write a service.
All extensions are disable for now.
Well, I follow bogdancovaciu advice to do a reset
But no luck after reboot, than I have to do manually ALT+F2, r, enter show "rebooting" but nothing append...
Is there other ways to reset GDM in my case ? (did not find anything in the forum)
dconf-editor maybe? my memory of gnome is fuzzy . i enjoyed using it at the time but i dont miss it by any means. sorry i cant be more helpful on that front.
Find "Manjaro Gnome Resetting Tool" app which aim to get a vanilla gnome session. Will try it later as I badly need my laptop tomorrow for a workshop. It has to work for two hours
Good news: 2 issues solved. Thanks tbg !
Reboot today on 5.0.14rt 9-1 kernel: bluetooth is working fine !
I did what you suggest to switch to r8169, and it automatically get installed. Ethernet is working fine even on resume after sleep !
And this file also disappear
I even create the service file you advice me to do with r8169 text instead of r8168 . But I did not enable it at first. Ethernet and bluetooth was working fine after reboot, so I enable the
network-restart.service and reboot (w/ the rt kernel)
Computer was not able to finish boot and get stuck after grub `
mount: /sys/firmware/efi/efivars: unknow filesystem type 'efivars'. [ 5.026905] 000: : BUG: scheduling while atomic:... ...
=> Hard reboot
So I came back to Kernel 5.0.18-1 without bluetooth and ethernet... Maybe I should try to stop and disable the network-restart.service ?
Will see. I hope other issues gets better with next updates (Nvidia driver always show up at 100% with powertop, and no lockscreen anymore )
Glad to hear your making some progress.
Disabling the service is very simple if you want:
sudo systemctl disable network-restart.service
Yes, I was guessing that, but wondering if it has to be stop first ?
And I feel stuck to the issues rather than progressing
Best practice is to stop it first but I don't think it matters that much. After disabling do a reboot.
I just disable the service and reboot but still the same message and no other way than a hard reboot. Back to kernel 5.0.18:
Edit: service is till loaded, should I remove the file ?
[philippe@Probook-450 ~]$ systemctl status network-restart.service ● network-restart.service - Network Suspend/Resume Service Loaded: loaded (/etc/systemd/system/network-restart.service; disabled; vendor preset: disabled) Active: inactive (dead)
What about the latest linux-firmware update, should I installed it ? or wait ?
Stop the service, then delete the service file, and restart.
Just did it, but rt kernel is simply unusable, always crash after grub
Yes sadly, some people reported the RT kernels fixed their bluetooth issues, but were unstable.
Thank you all for your help.
At that point, I'm thinking to restore my system as it was before may 26th, and to wait for next update. Does it makes sense ?
Forum kindly sponsored by Bytemark