Interesting.. I have a similar issue. I was actually about to send an email to this group list. After the kernel upgrade to 6.11.1.arch1-1, I am unable to wake my system up from sleep. For me it seems that the entire system freezes: monitors turn on and I see my lock screen but I cannot do anything; I cannot even switch to a different tty. Although, to be fair, I have not tried waiting as long as 90 seconds, I just force rebooted the computer after a while. That being said for me this clearly has nothing to do with any remote drives since I am not using any. So, it could be the case that my issue is a separate one from yours @set. Moreover, I am not sure whether my mouse cursor moves since I am using hyprlock and typically don't use the mouse until after I unlock the screen. I have also tried disabling display manager and compositor altogether and entered sleep directly from the console: same result, although in that case I can see that the underscore character in the console is blinking. For me there is nothing written to the log after the suspend log: Oct 07 11:00:24 sheldon (sd-pam)[3297]: pam_unix(login:session): session closed for user rahlir Oct 07 11:00:24 sheldon systemd[1]: Finished Turn on/off HW RGB before/after suspend. Oct 07 11:00:24 sheldon systemd[1]: run-u70.service: Deactivated successfully. Oct 07 11:00:24 sheldon systemd[1]: Reached target Sleep. Oct 07 11:00:24 sheldon systemd[1]: Starting System Suspend... Oct 07 11:00:24 sheldon systemd[1]: session-4.scope: Deactivated successfully. Oct 07 11:00:24 sheldon systemd-sleep[3356]: Successfully froze unit 'user.slice'. Oct 07 11:00:24 sheldon systemd-sleep[3356]: Performing sleep operation 'suspend'... Oct 07 11:00:24 sheldon kernel: PM: suspend entry (deep) Oct 07 11:00:24 sheldon kernel: Filesystems sync: 0.007 seconds Today I downgraded to 6.10.10.arch1-1 and waking up works fine again. I did notice that this kernel was the last one that came with linux firmware upgrade for me, don't know if that could have something to do with it... Also note that my system is fully an AMD one (both CPU and GPU). I am mentioning this because googling this issue I came across a couple of sites mentioning that this had to do with nvidia drivers. Cheers, Tadeas Uhlir On Sat, Oct 5, 2024 at 12:55 PM SET <set@xxxxxxxxxx> wrote: > > Hello, > > > I just upgraded a host and noticed a waiting of about 90s before the desktop (KDE) becomes responsive (typing to unlock the screen, the mouse cursor can be moved). This was not the case before the upgrade. > > > This box has 3 remote shares attached via sshfs. The delay to responsiveness is near immediate if it is suspended while the remote shares are not connected. > > > With remote shares connected on suspend: > > > [Sat Oct 5 12:05:03 2024] OOM killer enabled. > > [Sat Oct 5 12:05:03 2024] Restarting tasks ... done. > > [Sat Oct 5 12:05:03 2024] random: crng reseeded on system resumption > > [Sat Oct 5 12:05:03 2024] PM: suspend exit > > [Sat Oct 5 12:05:03 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control off > > [Sat Oct 5 12:06:35 2024] r8169 0000:06:00.0 eth0: Link is Down > > [Sat Oct 5 12:06:35 2024] Generic FE-GE Realtek PHY r8169-0-600:00: attached PHY driver (mii_bus:phy_addr=r8169-0-600:00, irq=MAC) > > [Sat Oct 5 12:06:35 2024] r8169 0000:06:00.0 eth0: Link is Down > > [Sat Oct 5 12:06:39 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control off > > > With remote shares disconnected on suspend: > > > [Sat Oct 5 12:10:55 2024] OOM killer enabled. > > [Sat Oct 5 12:10:55 2024] Restarting tasks ... done. > > [Sat Oct 5 12:10:55 2024] random: crng reseeded on system resumption > > [Sat Oct 5 12:10:55 2024] PM: suspend exit > > [Sat Oct 5 12:10:55 2024] Generic FE-GE Realtek PHY r8169-0-600:00: attached PHY driver (mii_bus:phy_addr=r8169-0-600:00, irq=MAC) > > [Sat Oct 5 12:10:56 2024] r8169 0000:06:00.0 eth0: Link is Down > > [Sat Oct 5 12:10:58 2024] r8169 0000:06:00.0 eth0: Link is Up - 1Gbps/Full - flow control off > > > It seems that the network link remains 'up' when the remote shares are connected, then has to go down and that's where the delay lies. Afterwards, it quickly returns to the up state. > > > 'modinfo r8169' does not expose any option at all. > > > I wish to know if there's a simple known solution to quickly resume the host. The root cause could also lie deep in the kernel and may perhaps disappear on a future upgrade. I can live with it, it's just annoying. > > > Thanks for any input. > >
