ThinkPad X1 Carbon 6th (Kaby Lake / UHD 620): internal eDP panel black after suspend/resume on kernel 7.0.x (HWE) — solved by reverting to GA kernel 6.8

[Tinux]

Hello everyone,

[The below bug solving was done with the assistance of Lumo (Proton AI agent) the summary was also created with the support of Lumo.]

I'd like to share a fully documented suspend/resume issue that is kernel-related, not Zorin 18.1-related: Zorin OS 18.1 Pro itself runs flawlessly on my machine — but the 18.1 upgrade brought the HWE kernel line (7.0.0-34/38) with it, and that kernel series breaks resume on this hardware. Reverting to the GA kernel 6.8.0-146 while staying on Zorin 18.1 Pro fixed everything.

---

Hardware

• Lenovo ThinkPad X1 Carbon 6th Generation
• Intel Core i7-8550U, Intel UHD Graphics 620 (Kaby Lake, KBL GT2)
• Zorin OS 18.1 Pro (Ubuntu 24.04 base), Wayland
• Kernels tested: 7.0.0-34, 7.0.0-38, 6.8.0-146

---

Symptoms (only on 7.0.x)

On the 7.0.x kernels that shipped with the 18.1 upgrade:

• Internal eDP panel stays black after suspend/resume. The system does wake (external monitor works fine, GPU is alive) — only the internal panel never comes back.
• Initially also a black screen after the splash on boot, plus panel flickering during use.

On the same machine, same OS version, kernel 6.8.0-146: no symptoms whatsoever — clean boot and suspend/resume fully functional, verified over three consecutive wake cycles.

---

Debugging Trail (Tested and Falsified)

Hypothesis	Test	Result
PSR race	i915.enable_psr=0 confirmed active during failure	Ruled out
DC-states	i915.enable_dc=0	Fixes boot/flicker, NOT resume
FBC	i915.enable_fbc=0	Rejected (boot delay/stall)
C-states	intel_idle.max_cstate=2	Too aggressive (boot fails)
Suspend mode	deep (S3) vs s2idle	Both fail on 7.0.x
Hibernate workaround	16 GB swapfile + resume= + resume_offset	Aborted before writing image (task freezing succeeded, image write aborted)
Kernel 7.0.0-34	Suspend test executed	Identical failure
Kernel 7.0.0-38	Current default	Same failure
Kernel 6.8.0-146	GA kernel from ubuntu noble main	Fully working

All standard i915 workarounds failed without breaking boot. The regression spans the entire 7.0.x line on this hardware — not a regression between point releases, but a systemic issue in that kernel branch.

---

Solution

The GA kernel 6.8.0-146 (Ubuntu noble main) works flawlessly. No kernel parameters needed at all — just the kernel itself:

`# /etc/default/grub
GRUB_DEFAULT="Advanced options for Zorin OS>Zorin OS, with Linux 6.8.0-146-generic"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

sudo update-grub
sudo apt-mark hold linux-image-generic-hwe-24.04 # prevent silent jump back to 7.0.x`

The apt-mark hold is essential: without it, the HWE meta-package pulls the system back onto 7.0.x on the next upgrade.

---

Note for Others

If you're on 8th-gen Intel (Kaby Lake) graphics and your internal screen dies after suspend while an external monitor works — regardless of which distro version you're running — the root cause is very likely the 7.0.x i915 resume path.

This is not a Zorin 18.1 issue: 18.1 runs perfectly on the GA kernel. The problem is the HWE kernel line that came with the 18.1 upgrade. Switching the kernel line (not the distro) is the shortest path to a working machine.

Kernel logs from failing cycles can be pulled with:

journalctl -b -0 -k --grep "suspend|resume|eDP|link training|hotplug"

On my failing boots, notable signals included:

• i915_hotplug_work_func [i915] hogged CPU for >13333us warnings
• GNOME Shell meta_monitor_manager_get_logical_monitor_from_number: assertion 'logical_monitor != NULL' failed — consistent with the eDP connector dropping out of the monitor list after resume.

---

Recommendation

If you maintain Zorin OS 18.1 or Ubuntu-based systems with Kaby Lake graphics, consider:

1. Documenting that kernel 7.0.x has known suspend/resume regressions on Intel UHD 620 (KBL GT2)
2. Not shipping 7.0.x as the default HWE kernel for 18.1, or providing explicit downgrade instructions
3. Users who encounter this: downgrade to the GA 6.8 kernel (sudo apt install linux-image-generic) and pin it as shown above

[Nourpon]

Glad it work for you to go back with 6.8, just a suggestion if you want to try, OEM kernel
Install the signed OEM kernel stack

Open your terminal and run this command:

sudo apt install linux-oem-6.17 -y

Once the installation finishes, update the boot configuration and restart your laptop:

sudo update-grub
sudo reboot

[Tinux]

Thank you for the feedback, I will give the OEM a try. Will report back with the result.

[Tinux]

Update 2026-10-10: Following @Nourpon advice, I tested the OEM kernel (linux-oem-6.17). Three consecutive green wake cycles confirmed on 6.17.0-1033-oem. So the final picture: 6.8 GA , 6.17 OEM (selected as default), entire 7.0.x . The regression is isolated to changes between 6.17 and 7.0 in the i915 resume path. I recommend the OEM kernel as the most sustainable path forward for Kaby Lake hardware on Zorin/Ubuntu 24.04.

[Forpli]

Isn't that oem kernel EOL so that the kernel won't get updates?

[Nourpon]

No, it's the OEM kernel, He will be update of course, I receive one 4days ago, An OEM kernel is created by Canonical engineers for specific brand-new hardware that is not yet supported by the (mainline) generic Linux kernel that everybody else uses
They will soon migrate to 7 branch

[Nourpon]

if you want to set OEM on grub and be sure to receive updates properly just add this to you grub

GRUB_DEFAULT=0
GRUB_FLAVOUR_ORDER=oem

[Nourpon]

But also you are not wrong, but Canonical do what he want, soon I will test hwe branch but I'm not fan of the update rhythm and the many regressions, and you see it everyday here !

[Tinux]

I was a bit too enthusiastic in calling 6.17 the most sustainable way to solve this issue. As long as 6.17 receives security updates, I'll keep using it. If the suspend issue in 7.0.x isn't fixed by the time 6.17 stops receiving updates, I'll fall back to 6.8, which has LTS support until 2029.

[Forpli]

Ah, thank you for the information. I thought, they had already migrated to 7.0 with oem, but they don't have. I think the 6.8 is the better long-term solution if the 7.0 kernel will still make problems after the next updates.

I didn't like the many updates of the 7.0 kernels, so I switched to 6.8 ga stack last week and removed the hwe kernel stack.

[wesoliv429]

been running the Liquorix kernel for 9 months now and none of the problems most are having has effected me at all

current version

now mine is a computer made around 2019 tho

[Tinux]

Thanks for sharing, your Liquorix experience. For now I will stay at my current set-up as I have a stable config now. . Will keep it in mind, because I had never heard of Liquorix before.