(SOLVED) Boot freezes without nomodeset

[SMG]

That time it froze at the login screen.

I don't see mention of the login screen, but the log did stop relatively early in the process.

I do see the noapic in the command line.

The fact this is happening on other distros as well is really pointing to a hardware situation. In my time helping others, I have seen and researched a lot of different error messages related to graphics, but I do not see any graphics error messages in your logs. The only reason of which I can think that using nomodeset is helping is because somehow the issue is in the CPU and the integrated graphics are interacting with whatever is the problem?

There are some CPU bugs mentioned.

Code: Select all

Aug 07 22:44:33 huy-Latitude-7490 kernel: MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.
Aug 07 22:44:33 huy-Latitude-7490 kernel: MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more details.

I do not have any other ideas of what to try or check at the present time.

[Huoi]

I googled the problem and found a workaround for the newer kernels: adding i915.enable_psr=0 to the parameters (without nomodeset).

It booted flawlessly and I could even change the resolution (just like with the noapic situation).

The difference is that after rebooting and adding i915.enable_psr=0 again, it no longer froze!

However, I am still testing to see if there is a certain point when my laptop will freeze again.

*Update: it doesn't freeze after multiple reboots. However, the laptop can't be put to sleep, as it will not wake up (also, Linux Mint entry was replaced by Ubuntu in the GRUB menu, no idea why)

[SMG]

I googled the problem and found a workaround for the newer kernels: adding i915.enable_psr=0 to the parameters (without nomodeset).

I have recommended that kernel parameter to many people, but it was to get around different issues than what you described. I would not have guessed it would help with this type of situation (or I would have recommended it), but glad to hear it is working for you.

psr=panel self-refresh
It is a type of "energy savings" setting with regards to battery life. Painting the screen is a power-consuming operation so the less it is done, the longer the battery lasts.

*Update: it doesn't freeze after multiple reboots. However, the laptop can't be put to sleep, as it will not wake up (also, Linux Mint entry was replaced by Ubuntu in the GRUB menu, no idea why)

I have not received any feedback in the past where that kernel parameter affected suspension, but that feedback was with older kernels. Perhaps the psr code has been changed in the i915 driver in the 5.15 kernel.

Try restarting the X Server the next time it does not come out of sleep. You can do that with Ctl-Alt-Backspace.

If that does not work and you are pressing the power button to restart the laptop, we can check logs again for messages. This time, let's just key in on the i915 driver.

Code: Select all

journalctl -b -1 | grep -i "drm\|i915"

This should be relatively short output, so post the output between code tags in a post here.

[Huoi]

Code: Select all

Aug 10 16:24:36 huy-Latitude-7490 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-43-generic root=UUID=d0eb2a2b-f24e-44b3-ad17-bdb346d7bd6b ro quiet splash i915.enable_psr=0
Aug 10 16:24:36 huy-Latitude-7490 kernel: Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-43-generic root=UUID=d0eb2a2b-f24e-44b3-ad17-bdb346d7bd6b ro quiet splash i915.enable_psr=0
Aug 10 16:24:36 huy-Latitude-7490 kernel: fb0: switching to i915 from EFI VGA
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: [drm] [ENCODER:118:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
Aug 10 16:24:36 huy-Latitude-7490 kernel: [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
Aug 10 16:24:36 huy-Latitude-7490 kernel: fbcon: i915drmfb (fb0) is primary device
Aug 10 16:24:36 huy-Latitude-7490 kernel: i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
Aug 10 16:24:36 huy-Latitude-7490 systemd[1]: Starting Load Kernel Module drm...
Aug 10 16:24:36 huy-Latitude-7490 systemd[1]: modprobe@drm.service: Deactivated successfully.
Aug 10 16:24:36 huy-Latitude-7490 systemd[1]: Finished Load Kernel Module drm.
Aug 10 16:24:37 huy-Latitude-7490 kernel: mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
Aug 10 16:24:37 huy-Latitude-7490 kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Aug 10 16:24:46 huy-Latitude-7490 kernel: i915 0000:00:02.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS

However, I don't think the suspend problem relates to the i915 parameter. So I included another journalctl -rb -1:

https://termbin.com/anmr

[SMG]

*Update: it doesn't freeze after multiple reboots. However, the laptop can't be put to sleep, as it will not wake up

I went through the log file you posted. I did not see any messages in it to tell the operating system to go to sleep. How are you putting the computer to sleep?

I did notice this in the log. These two lines are sequential. That seems like a big time correction. I don't know the significance (if any) of it.

Code: Select all

Aug 10 16:25:11 huy-Latitude-7490 systemd[1]: blueman-mechanism.service: Deactivated successfully.
Aug 10 09:25:10 huy-Latitude-7490 systemd-resolved[700]: Clock change detected. Flushing caches.

However, I don't think the suspend problem relates to the i915 parameter.

i915 is not a parameter. It's the Intel graphics driver module from the kernel.

[Huoi]

https://termbin.com/xv50

An interesting discovery: pm-suspend works and I was able to wake up from it, but it didn't lock the screen.

systemctl suspend however, when woken up I was able to see the login screen for a split second, then it went to black screen (had to force power down).

[SMG]

An interesting discovery: pm-suspend works and I was able to wake up from it, but it didn't lock the screen.

I'm starting to get confused about what problem you want help with. This topic was original about boot freezes which seems to have been resolved. You then started discussing suspend issues and now you are talking about screensaver lock. Are these somehow related in a way I'm just not noticing?

systemctl suspend however, when woken up I was able to see the login screen for a split second, then it went to black screen (had to force power down).

There's a coredump from Timeshift in that log.

The coredump happened about an hour before you put the computer to sleep with pm-suspend.

Code: Select all

Aug 11 10:58:21 huy-Latitude-7490 sudo[7401]:      huy : TTY=pts/8 ; PWD=/home/huy ; USER=root ; COMMAND=/usr/sbin/pm-suspend

About 9 seconds later it woke up.

Code: Select all

Aug 11 10:58:30 huy-Latitude-7490 kernel: PM: suspend exit

Then I see the below line, but I'm not sure what triggered it. It's the first sign the computer is going back to sleep (even though it is only 30 seconds later).

Code: Select all

Aug 11 10:59:01 huy-Latitude-7490 ModemManager[925]: <info>  [sleep-monitor] system is about to suspend

Two seconds later it reached target sleep. Power was cut to the computer which stopped the logging, but I do not know when that happened in relation to when the computer was put to sleep.

It takes a while for messages to be recorded so if you are going to test sleep, it is better to let it sleep for a while (many minutes instead of many seconds).

[Huoi]

I'm starting to get confused about what problem you want help with. This topic was original about boot freezes which seems to have been resolved. You then started discussing suspend issues and now you are talking about screensaver lock. Are these somehow related in a way I'm just not noticing?

My bad, I kinda got carried away @@.

I am going to mark this topic as solved, as I found a solution.

For the suspend problem, I will look into it on my own.

Thank you for the help!

[Nikolai5]

For the suspend problem, I will look into it on my own.

It's always worth seeing if Google can answer your questions, but I'm sure they aren't saying that you can't ask for help about that, just that if you do, you should do so as a new forum post, rather than use this one.

[SMG]

For the suspend problem, I will look into it on my own.

You are welcome to create a topic on this forum for it, but suspension is not an "Installation & Boot" issue. Probably best to create it in "Other Topics" unless you have a good suspicion of what is the source of the problem.

We ask people to limit their questions to the topic of the initial post and not add new questions unrelated to the initial issue. That makes it easier for people helping and also easier for people searching for solutions in the future.

New topics get more attention than adding posts to existing topics so you are likely to get more ideas from a wider variety of people if you create the new topic for this suspension issue.