[REGRESSION?] i915 CoffeeLake: HPD poll work hogged CPU escalating to hard kernel panic with HDMI->VGA adapter (7.0.0-38)

[Theron]

Hello,

Reporting an i915 display issue on CoffeeLake-H (UHD Graphics 630) with an
active HDMI->VGA adapter, where the i915 HPD polling workqueue progressively
hogs the CPU and the system ends in an unrecoverable kernel panic (drm_panic,
no TTY, no SysRq).

This closely matches existing issue #14777 on the drm/i915 tracker
(https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14777), which is
tagged platform: SKL. The hogged-CPU progression sequence is numerically
identical (4 -> 5 -> 7 -> 11 -> 19 times), suggesting the same root cause on a
different platform generation. I could not add a comment there because
registration on gitlab.freedesktop.org requires reCAPTCHA + Arkose Labs
verification, so I am reporting here instead. Happy to file on the tracker if
that is preferred.

== Hardware ==

Intel Core i7-8750H, CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b]
ASUS TUF GAMING FX504GE_FX80GE (TUF GAMING FX504GE_FX80GE, BIOS FX504GE.323, 2021-08-23)
Hybrid graphics: NVIDIA GeForce GTX 1050 Ti present but unused for display
23 GiB RAM

00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b] (prog-if 00 [VGA controller])
	Subsystem: ASUSTeK Computer Inc. CoffeeLake-H GT2 [UHD Graphics 630] [1043:18fe]
	Kernel driver in use: i915
	Kernel modules: i915

== Software ==

Linux thor 7.0.0-38-generic #38~24.04.4-Ubuntu SMP PREEMPT_DYNAMIC Mon Sep 14 16:37:11 UTC 2026 x86_64
Ubuntu 24.04.5 LTS
X11 / GNOME (Xorg)
Kernel command line:
  BOOT_IMAGE=/boot/vmlinuz-7.0.0-38-generic root=UUID=... ro quiet splash
  i915.enable_psr=0 i915.enable_dc=0 i915.enable_atomic_modesetting=0 vt.handoff=7

Note: i915.enable_atomic_modesetting=0 is rejected by this kernel version --
dmesg contains "i915: unknown parameter 'enable_atomic_modesetting' ignored" --
so that particular workaround is no longer available.

== Setup ==

Internal eDP-1 panel plus an external VGA monitor driven through an active
HDMI->VGA adapter on the card1-HDMI-A-1 connector. Both connectors report
"connected". The VGA adapter is the trigger: unplugging it stops all i915
errors completely.

== Symptoms ==

Two symptom sets appear together and escalate over hours, not minutes:

1. i915 HPD polling workqueue progressively hogging the CPU:

12:34:55 workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
12:35:37 workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 5 times, consider switching to WQ_UNBOUND
12:40:33 workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 7 times, consider switching to WQ_UNBOUND
12:44:00 workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 11 times, consider switching to WQ_UNBOUND
12:54:00 workqueue: i915_hpd_poll_init_work [i915] hogged CPU for >10000us 19 times, consider switching to WQ_UNBOUND

2. Continuous i915 atomic update failures over the same period, ~30 occurrences
across ~7 hours, continuing until the hang:

i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=70610 end=70611) time 173 us, min 1064, max 1079, scanline start 1063, end 1087
i915 0000:00:02.0: [drm] *ERROR* Atomic update failure on pipe A (start=153656 end=153657) time 164 us, min 1064, max 1079, scanline start 1061, end 1086

Eventually the kernel panics: the display shows the drm_panic Tux logo, TTY
switching stops working, SysRq REISUB does not respond, and only the physical
power button recovers the machine.

== Frequency ==

Infrequent -- roughly once every few days of normal use with the adapter
connected. The machine is otherwise stable; this has not been observed with the
external display unplugged.

== Logging problem (important for triage) ==

The panic itself leaves no journal record, because the machine hard-locks and
the journal cannot be flushed to disk. /sys/fs/pstore is empty (no ramoops
configured). So the escalation pattern quoted above is the only pre-crash
evidence available, and the last kernel message before the lockup was an i915
atomic update failure roughly 10 minutes prior.

I can reproduce the pre-crash state on demand by reconnecting the adapter, and
I am willing to run with drm.debug=0xe log_buf_len=4M ignore_loglevel and
provide full dmesg if that would help.

== Observations that may help triage ==

1. Writing "reset" to /sys/kernel/debug/dri/1/i915_hpd_storm_ctl clears the HPD
   storm counters (per intel_hotplug.c, the write path restores the threshold
   default and zeroes every pin's stats). This is consistent with the HPD storm
   machinery being involved, and it is the basis for a userspace watchdog I am
   running that attempts an HPD reset before falling back to restarting gdm.

2. The existing i915.enable_psr=0 and i915.enable_dc=0 parameters on this
   cmdline were added earlier for a separate issue (external display blackout
   after suspend/resume) and do not prevent this problem.

== Question ==

Given that #14777 shows the identical escalation sequence on Skylake, is this
worth filing as a separate CoffeeLake instance on the drm/i915 tracker, or
should it be folded into #14777 as a multi-platform confirmation? I will file
wherever preferred once I have tracker access.

Regards,
Theron
theron@xxxxxxxx