System Freeze on Wake-up
After a period of inactivity when returning to machine the mouse is responsive but no shortcuts or applications are. Cannot re-launch Hyprland and requires hard machine restart.
I experienced the same issue, and I'm wondering if it's related to the nvidia open driver. @itsnumpty Do you have nvidia drivers installed?
I experienced the same issue, and I'm wondering if it's related to the nvidia open driver. @itsnumpty Do you have nvidia drivers installed?
Yes, I'm running nvidia drivers.
Related #4
https://wiki.hypr.land/Nvidia/#suspendwakeup-issues maybe related to this issue but I need logs :)
Useful things to include in your bug reports: Crashing? The crash report The log Your config: hyprctl systeminfo -c Always attach them as files, do not paste them!
@Kn0ax thanks for the response. I tried enabling crash reporting in the config (attached) and triggered the suspend systemctl suspend and then woke the machine up. This repeated the issue so I hard restarted the machine but following the retrieving the crash report you linked:
cat $XDG_RUNTIME_DIR/hypr/$(ls -t $XDG_RUNTIME_DIR/hypr/ | head -n 2 | tail -n 1)/hyprland.log
'No such file or directory' was found.
I've run a grep for 'nvidia' in the journalctl and attached the logs as well.
nvidia-suspend.log hyprctl_systeminfo.txt journalctl-nvidia.log
@itsnumpty sorry it took a bit to reply :')
Can you run share outputs of these command too?
cat /proc/driver/nvidia/params | sort
sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st
Also Is there any chance that you have a dual boot setup with Windows?
Also please be sure running latest bios :)
I've got this issue as well (nvidia 4070) and noticed it seems happen when the monitor signal is turned off as a result of the hypridle command hyprctl dispatch dpms off . If I run that command from the terminal to test, it will shut down the screen and most times screen will not wake back or is frozen. I can fire up an alternate tty and the monitor will come back for that.
Waking from the full sleep state (induced with shortcut key) seems to works fine, which is strange. The issue just seems to be when the monitor sleeps.
This machine does have dual boot option with windows by selecting the startup drive in bios, but the EFI partitions are independent, so not really dual boot with a shared boot loader.
CreateImexChannel0: 0
DeviceFileGID: 0
DeviceFileMode: 438
DeviceFileUID: 0
DmaRemapPeerMmio: 1
DynamicPowerManagement: 3
DynamicPowerManagementVideoMemoryThreshold: 200
EnableDbgBreakpoint: 0
EnableGpuFirmware: 18
EnableGpuFirmwareLogs: 2
EnableMSI: 1
EnablePCIeGen3: 0
EnablePCIERelaxedOrderingMode: 0
EnableResizableBar: 0
EnableS0ixPowerManagement: 0
EnableStreamMemOPs: 0
EnableUserNUMAManagement: 1
ExcludedGpus: ""
GpuBlacklist: ""
GrdmaPciTopoCheckOverride: 0
IgnoreMMIOCheck: 0
ImexChannelCount: 2048
InitializeSystemMemoryAllocations: 1
KMallocHeapMaxSize: 0
MemoryPoolSize: 0
ModifyDeviceFiles: 1
NvLinkDisable: 0
OpenRmEnableUnsupportedGpus: 1
PreserveVideoMemoryAllocations: 1
RegisterPCIDriver: 1
RegistryDwords: ""
RegistryDwordsPerDevice: ""
ResmanDebugLevel: 4294967295
RmLogonRC: 1
RmMsg: ""
RmNvlinkBandwidthLinkCount: 0
RmProfilingAdminOnly: 1
S0ixPowerManagementVideoMemoryThreshold: 256
TemporaryFilePath: "/var/tmp"
UsePageAttributeTable: 4294967295
VMallocHeapMaxSize: 0
http://wiki.archlinux.org/title/Dual_boot_with_Windows#Fast_Startup_and_hibernation
Please try to disable Fast startup and make sure windows fully closed.
I also observed that the issue occurs only when the monitor goes to sleep and then wakes up; there is no crash. I'm only getting all windows with the bar, but nothing can be clicked. Maybe the lock process is still active but somehow not bound to the screen after the wake-up?
@mmaadd without logs we can't help :(
I've changed the config to sleep 10 seconds after starting Hyprland. The issue only occurs when I wait an additional couple of seconds, and the monitor switches off completely
@Kn0ax no problems! I've attached the outputs you've requested. Similar to @mmaadd it does also seem related to the monitor state.
Yes, I am on a dual boot Windows but with separate EFI partitions.
Have the same issue with a 50-series GPU. As far as I can tell, I am doing everything the way I am supposed to do it (must evidently have a mistake somewhere) according to the Hyprland docs. Fast startup is disabled in BIOS, and the same goes for the AMD iGPU which is also disabled in BIOS.
Reading deeper into the Hyprland docs, the freezing upon hibernation/sleep does seem to be a not so infrequent problem, but even attaching the kernel parameter as suggested by the Hyprland docs does not seem to accomplish much afaict.
Here is the log: http://0x0.st/8G2o.txt
Looking through, libwayland-client.so does seem to be one of the main issues
Jul 07 00:08:17 Kislev kernel: xdg-desktop-por[2651]: segfault at 64 ip 00007f7666df18ac sp 00007ffec7471750 error 6 in libwayland-client.so.0.23.1[58ac,7f7666def000+6000] likely on CPU 29 (core 13, socket 0)
Looking at the log by @itsnumpty , the same issue exists there. libwayland-client segfaults.
To add to the above, filtered journalctl just for all Wayland, and it looks pretty damning:
http://0x0.st/8G2A.txt
@itsnumpty @mmaadd @ehutzelman what is your output of cat /proc/cmdline if I may ask?
I am still try to debug this sorry it took a bit long. @ludgerpaehler thanks for additional findings.
I think the issue is in the kernel variables, especially for the ZSwap. I’ll only be able to try it out later tonight though
This is very easily reproducible for me... not much in the logs that I can see. Output for /proc/cmdline for me is:
initrd=\initramfs-linux.img cryptdevice=PARTUUID=eb92ae1a-95af-4c25-ab06-821760f170c1:root root=/dev/mapper/root zswap.enabled=0 rw rootfstype=ext4
Set the system up anew without the Zswap, but am still facing the same issue. So the above surmised root of the problem is not the issue. (Even when Zswap has its whole own host of issues)
@Kn0ax do you think it is possible that the 3 services created, namely:
- NVIDIA-suspend.service
- nvidia-hibernate.service
- NVIDIA-resume.service Do not engage properly the way they are supposed to?
Reason why I am asking is, when I forced it to hibernate through the systemctl command. The services engaged properly and everything worked perfectly fine. But then when the system hibernated itself, it froze upon waking up.
Ok, localized the error by now:
- The sleep statement in
hypridledoes not engage properly, i.e. thedpmsstatements somehow mess up - Comment out the sleep statement in
hypridlefor now and things should work properly
The tell in the end was that when the lock engages properly before sleep, one can wake up properly without the system freezing. On the actual freezes the lock was never engaged.
Not sure yet how to best fix it, but might require some changes within hypridle.
@dhh maybe it'd be worth adding a remark in the Docs for this
Even asking around in the Hyprland Discord, people don't really seem to know a solution for this and have also stopped using Hyprland's sleep function.
Maybe we can get @vaxerski's take on this before yanking it.
dpms off, display goes to sleep, and then can't wake up? does it get modeset correctly (i.e. is there anything visible like a cursor) and can I get a trace log from that
dpms off, display goes to sleep, and then can't wake up? does it get modeset correctly (i.e. is there anything visible like a cursor) and can I get a trace log from that
KMS set by Nvidia-dkms.
https://gitlab.archlinux.org/archlinux/packaging/packages/nvidia-utils/-/blob/main/0001-Enable-atomic-kernel-modesetting-by-default.patch
After a period of inactivity when returning to machine the mouse is responsive but no shortcuts or applications are. Cannot re-launch Hyprland and requires hard machine restart.
I have the same issue as described here. I thought my machine was frozen. I ssh'd to my machine and could see errors saying incorrect password. I realised that the lock screen is not displaying yet it is waiting for the password. If I enter my password then everything starts working again. I can consistently reproduce this.
Looks like this is expected behavior if hyperlock is not configured correctly.
Hyprlock does not automatically create a config, and without one, hyprlock will not render anything, meaning you will just see your screen, but it will be locked and require a password followed by an enter to unlock.
I think the issue is with hyperlock.conf
I will debug further. I wonder if it is related to these changes -
https://github.com/basecamp/omarchy/commit/77524a7afadd92e3cd834d0d376352602af3e1dc
prior to running omarchy-update I was seeing the lockscreen.
Think this issue is due to an incomplete hyprlock.conf - Debugged with Grok.
Replacing ~/.config/omarchy/current/theme/hyprlock.conf with the following hardcode resolves the issue on my X1 carbon gen11.
This was just a quick test before bed. Someone else can probably push a proper fix on this faster than me, I'm flying out early tomorrow morning.
# Tokyo Night theme for Hyprlock
$color = rgba(26,27,38,1.0) # #1a1b26 solid color
$inner_color = rgba(26,27,38,0.8) # #1a1b26 with opacity
$outer_color = rgba(205,214,244,1.0) # #cdd6f4
$font_color = rgba(205,214,244,1.0)
$placeholder_color = rgba(205,214,244,0.6)
$check_color = rgba(68, 157, 171, 1.0)
background {
monitor =
color = $color # Solid background color
# Optional: path = /path/to/image.png # Uncomment and specify a valid image path if desired
blur_passes = 0 # Disable blur for simplicity
}
input-field {
monitor =
size = 300, 50
outline_thickness = 3
outer_color = $outer_color
inner_color = $inner_color
font_color = $font_color
fade_on_empty = false
placeholder_text = Enter password...
placeholder_color = $placeholder_color
check_color = $check_color
position = 0, -20
halign = center
valign = center
}
Further investigation and seeing comments in the Discord a proper omarchy-update all that runs the migrations fixes this issue for me