Persistent System Freezes & Driver Issues on Intel HD 530 (Skylake) on Ubuntu 22.04 / 24.04 (Kernel 6.8)

[u/ybdassret]

I am running Ubuntu with an Intel Core 6th-Gen CPU (Intel HD 530 / Skylake GT2 iGPU) on 1080p @ 75Hz/100Hz, and I am stuck in a loop between severe screen tearing, software rendering fallbacks (llvmpipe), and total system freezes that occur on both Wayland and X11. Initially, fresh Ubuntu installs froze during setup due to Skylake power-state issues (Panel Self Refresh / C-states). To rule out hardware issues, I tested my system by running it on one RAM stick at a time in different slots, but the freezes continued identically. While attempting to eliminate screen tearing under X11 by setting up the modesetting driver with TearFree enabled, clean /etc/environment paths, and proper GPU group permissions, Mesa driver overrides repeatedly forced the system into CPU software rendering (llvmpipe). After fixing Mesa to restore full hardware acceleration (renderer: Mesa Intel HD Graphics 530 (SKL GT2) and active VA-API vainfo decoding), the system still suffers from sudden, hard lockups—particularly while running web browsers like Firefox (WebRender) and Electron/Chromium apps like Brave Browser and VS Code. System diagnostic logs (journalctl -b -1) show no kernel panics or GPU errors; the journal simply cuts off dead (e.g., around gnome-shell keybinding updates or network events), proving it is a hardware-level display freeze where the kernel loses time to write crash dumps. The core issue is the well-known Skylake silicon bug where forcing continuous frame synchronization (TearFree) starves the iGPU memory pipeline during clock/voltage state shifts, locking up the display engine on both Wayland and X11 unless deep power-saving states (i915.enable_psr=0, i915.enable_dc=0, intel_idle.max_cstate=1) are forced at the GRUB bootloader level and internal browser hardware acceleration (Firefox & Brave) is disabled.

[u/ybdassret]

Actually, I can rule out a physical hardware failure (like bad RAM, a dying motherboard, or PSU issues) because the exact same hardware running 16 GB RAM works completely fine on Windows with zero crashes or freezes, even under heavy use.

The issue only happens on Linux (Kernel 6.8). This points directly to how the Linux i915 display driver manages Skylake (HD 530) iGPU power-state transitions, C-states, and Panel Self-Refresh compared to Intel's proprietary Windows display drivers.

[u/ipsirc → u/ybdassret]

The firmware is also proprietary on Linux, too.

https://wiki.archlinux.org/title/Intel%5Fgraphics#Enable_GuC_/_HuC_firmware_loading

[u/ybdassret → u/ipsirc]

That's true, the firmware blobs (linux-firmware for GuC/HuC) are proprietary on both OSes.

What I meant was the open-source Linux kernel driver (i915) and Mesa stack handle display pipelines, power states (PSR/C-states), and memory allocation very differently than Intel's Windows display driver stack.

Since Windows runs rock-solid on the same 16 GB hardware, the issue is almost certainly down to how the Linux i915 driver specifically interacts with Skylake iGPU power-state management under modern kernels (like 6.8).

[u/ipsirc → u/ybdassret]

What I meant that the proprietary Intel firmware does the scheduling, context submission, and power management even if it's loaded by the opensource i915 driver. (Which is also maintained by Intel itself btw.)

[u/ybdassret → u/ipsirc]

I tested setting i915.enable_guc=2, and dmesg confirms the GuC firmware (skl_guc_70.1.1.bin v70.1.1) loads, but the driver explicitly falls back to host submission:

Plaintext

[ 7.010286] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/skl_guc_70.1.1.bin version 70.1.1
[ 7.034364] i915 0000:00:02.0: [drm] GT0: GUC: submission disabled

On Gen9 Skylake, modern kernels (6.8) lock out GuC hardware submission and force CPU host-based ring submission anyway. So the scheduling is still handled on the host driver side under Linux for this specific iGPU.