Laptop freezes when idle with 6.4.x kernel

Ask Fedora
, ,
1

With the current 6.4.4 kernel, and the 6.4.6 kernel from koji, when my laptop sits idle for more that 15 minutes (not a precise time, just an estimate based on observations), the screen is blank and it remains powered on, but nothing I can do will get the screen to come back on. I don’t know if it is just the display no being responsive or if the system as a whole is locked. This behavior does not occur with the 6.3.13 (i am currently booting into that) nor does it occur with 6.2.9.

I am looking for suggestions on what I can do to try and track this down or provide better information to help others help me, or a solution if someone knows one.

Some details:

  • This occurs when my laptop is plugged into AC power and I have disabled suspend when on AC power.
  • It is an Intel i7-9750H processor
  • Has Intel UHD Graphics 630 and a Nvidia GeForce GTX 1650 Mobile / Max-Q
  • I do not have the Nvidia drivers installed as I don’t currently do anything that needs it and thus just run off of the integrated graphics
  • I’ve looked through logs via journalctl trying to find something that stands out as a possible issue but haven’t come across anything, but that could just be me not realizing the significance of something.
  • I can consistently replicate the behavior if I boot back into a 6.4.x kernel

Thanks for any help

2

You might need to add a kernel argument you had used before?

sudo grubby --info ALL
3

Thank you. I ran that and the args are consistent across all kernel versions. I’ve not ever changed anything so I don’t there is anything there.

args="ro rootflags=subvol=root rd.luks.uuid=luks-b39dfb3e-866a-4294-b87c-80af5f65229a rhgb quiet"

4

Could it be that you run then nvidia services without using it? Or viz versa?

5

Thank you again.

I do not have the Nvidia drivers installed so there is no Nvidia service. Nouveau is there but the display is driven by the integrated graphics. That isn’t to say that nouveau isn’t somehow causing an issue as I’ve seen the nvidia driver in hybrid mode cause issues even if not being used.

I want to be clear that this shouldn’t be a suspend issue, or at least I have it configured so I don’t suspend when on AC power via GNOME settings. That is, unless something is going on to try and suspend when it is not supposed to. But if it is, it is not something I can recover from without just holding down the power button.

6

Exactly, this is what I think. Not using the NVIDIA driver not means that your system not recognizes the NVIDIA GPU.

Did you follow the discussions we had some weeks ago about the suspend who happens on Gnome by default after 15 min.? And yes, the settings in gnome not cover all switches you will need to turn that off.

Please skim also the links underneath the article.

7

I had looked that prior to posting, albeit not in a lot of detail. It did not seem to apply to my situation because 1) I have always disabled suspend when on AC power on F38 and it hasn’t been and issue and 2) the only variable right now seems to be the kernel version (6.2.9 and 6.3.13 are fine, 6.4.4 and 6.4.6 are not)and thus I didn’t think GNOME settings would be at play.

However, I did re-read and made an adjustment to the GDM settings per the post. I did not have high hopes for that since I am logged in and figure the GNOME settings would apply, but you never know. Sadly, disabling suspend on AC power in GDM had no effect.

For that test I shut down and then powered back up using the 6.4.4 kernel. I logged into my desktop and then let it sit. I logged in around 11:46 my time. By 12:12 I found it unresponsive and I had to power it off via holding down the power button. I did grab some stuff from journalctl and pasted below. Regarding the times:

  • 11:56:?? - I was successfully logged in and just let the desktop sit
  • 11:47:06 - geoclue indicates it has been idle for 60 seconds which makes sense
  • 11:52:02 - This is the last log entry before I had to hard power off and start up again. This is approximately 5 minutes after I logged in let it sit, so the screen would have blanked here.
  • 12:13:01 - Boot process starting based on me having to power off the laptop. But we have nothing for the past 20 minutes
Jul 25 11:47:06 fedora geoclue[2165]: Service not used for 60 seconds. Shutting down..
Jul 25 11:47:06 fedora systemd[1]: geoclue.service: Deactivated successfully.
Jul 25 11:47:06 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=geoclue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 25 11:47:08 fedora realmd[2453]: quitting realmd service after timeout
Jul 25 11:47:08 fedora realmd[2453]: stopping service
Jul 25 11:47:08 fedora systemd[1]: realmd.service: Deactivated successfully.
Jul 25 11:47:08 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=realmd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 25 11:47:15 fedora systemd[2735]: Starting gvfs-metadata.service - Virtual filesystem metadata service...
Jul 25 11:47:15 fedora systemd[2735]: Started gvfs-metadata.service - Virtual filesystem metadata service.
Jul 25 11:47:19 fedora chronyd[1616]: Selected source 138.236.128.36 (2.fedora.pool.ntp.org)
Jul 25 11:48:04 fedora systemd[1]: virtqemud.service: Deactivated successfully.
Jul 25 11:48:04 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=virtqemud comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 25 11:49:02 fedora systemd[2735]: Starting grub-boot-success.service - Mark boot as successful...
Jul 25 11:49:02 fedora systemd[2735]: Finished grub-boot-success.service - Mark boot as successful.
Jul 25 11:50:34 fedora chronyd[1616]: Selected source 162.159.200.123 (2.fedora.pool.ntp.org)
Jul 25 11:51:27 fedora PackageKit[2196]: daemon quit
Jul 25 11:51:27 fedora systemd[1]: packagekit.service: Deactivated successfully.
Jul 25 11:51:27 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=packagekit comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Jul 25 11:51:27 fedora systemd[1]: packagekit.service: Consumed 4.531s CPU time.
Jul 25 11:52:02 fedora systemd[2735]: Created slice background.slice - User Background Tasks Slice.
Jul 25 11:52:02 fedora systemd[2735]: Starting systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories...
Jul 25 11:52:02 fedora systemd[2735]: Finished systemd-tmpfiles-clean.service - Cleanup of User's Temporary Files and Directories.
-- Boot 77ffd593a4854586bf1e713faa53a5df --
Jul 25 12:13:01 fedora kernel: microcode: updated early: 0xb4 -> 0xf2, date = 2023-01-12
Jul 25 12:13:01 fedora kernel: Linux version 6.3.13-200.fc38.x86_64 (mockbuild@dbc5e10948314e2e84930a09552890ad) (gcc (GCC) 13.1.1 20230614 (Red Hat 13.1.1-4), GNU ld version 2.39-9.fc38) #1 SMP PREEMPT_DYNAMIC Wed Jul 12 13:46:27 UTC 20>
Jul 25 12:13:01 fedora kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.3.13-200.fc38.x86_64 root=UUID=6a6fda91-f19a-4b36-aae4-e67f899ebd81 ro rootflags=subvol=root rd.luks.uuid=luks-b39dfb3e-866a-4294-b87c-80af5f65229a rhgb quiet
8

For the record, I’ve also tried setting all of the Allow* settings to “no” in /etc/systemd/sleep.conf just to see if that helped. Nothing helped there.

For now, I’ll just continue with the 6.3.x kernel and keep trying new 6.4.x kernels when they come up, and I’ll keep checking around to see if this comes up for anyone else.

9

This ended up getting resolved with the 6.4.8 kernel upgrade. I don’t know what specific change in there resolved it, but everything started working normally again after I upgraded (I tried from a COPR repository first and that worked, and then just used the normal upgrade when it was available).

1 Like