Public bug reported:
What I expected
With two HDMI displays attached and nothing being plugged or unplugged,
the Intel display hotplug / connector polling work should sit idle, and
the kernel should not warn about it.
What happens instead
The hotplug-poll work is re-armed continuously, roughly once every 10
seconds, indefinitely, and every execution exceeds 10 ms of CPU. The
kernel therefore logs workqueue hog warnings for the Intel display
hotplug path and for drm_kms_helper connector polling.
Present in 13 of the last 15 boots on this machine, and on kernels
7.0.0-29, -30 and -31.
No threshold-based storm detection ever fires. This message does NOT
appear in any retained boot:
HPD interrupt storm detected on connector ...: switching from
hotplug detection to polling
So this is not the classic HPD storm case; the polling path is simply
being re-armed continuously and each run is expensive.
Steps to reproduce
1. Boot with two HDMI displays attached.
2. Leave the machine idle until the screen blanks via DPMS, then wake it.
(Not S3 suspend — plain idle screen blanking is enough.)
3. Wait. The warnings then accumulate indefinitely, with an unchanged
machine configuration.
Log excerpt, one boot, uptime 2 days 9 hours
2026-09-11T12:59:33+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 4 times
2026-09-11T12:59:47+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 7 times
2026-09-11T13:00:35+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 19 times
2026-09-11T13:04:18+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 67 times
2026-09-11T20:53:34+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 515 times
2026-09-12T03:52:37+08:00 kernel: workqueue: output_poll_execute hogged CPU
for >10000us 2051 times
2026-09-12T11:27:52+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 8195 times
2026-09-12T11:50:52+08:00 kernel: workqueue: output_poll_execute hogged CPU
for >10000us 4099 times
2026-09-13T01:58:38+08:00 kernel: workqueue: i915_hpd_poll_init_work [xe]
hogged CPU for >10000us 16387 times
2026-09-13T04:29:10+08:00 kernel: workqueue: output_poll_execute hogged CPU
for >10000us 8195 times
i915_hpd_poll_init_work crossed the 10 ms threshold 16387 times in that
window, i.e. roughly once per 10 s. output_poll_execute reached 8195.
The workqueue function is the shared Intel display code, so the same
warning appears whether the device is bound to i915 or to xe; under xe
it is tagged [xe]. output_poll_execute lives in drm_kms_helper and is
shared by every KMS driver.
Note on the counters — they are NOT growing exponentially
The logged counts read 4, 5, 7, 11, 19, 35, 67, 131, 259, 515, 1027,
2051, 4099, 8195, 16387 and look like exponential growth. They are not.
That is the kernel's throttled logging cadence: the interval between
log lines doubles each time, while the counter advances uniformly.
Measured intervals for the sequence above: 5 s, 9 s, 16 s, 32 s, 83 s,
140 s, then about 7 hours. A genuine escalation would keep the interval
constant while the count accelerates.
Machine / software versions
$ lsb_release -rd
Description: Ubuntu 26.04.1 LTS
Release: 26.04
$ cat /proc/version_signature
Ubuntu 7.0.0-31.31-generic 7.0.14
$ apt-cache policy linux-image-generic-hwe-26.04
Installed: 7.0.0-31.31
Candidate: 7.0.0-31.31
Also reproduced on linux 7.0.0-29 and 7.0.0-30.
Hardware
CPU/iGPU : Intel Core i5-14400 / Raptor Lake-S UHD Graphics
[8086:a782] (rev 04)
Outputs : HDMI-A-1 connected, HDMI-A-2 connected, both 1920x1080 @ 60 Hz
HDMI-A-3, DP-1, DP-2, DP-3 disconnected
Desktop : GNOME Shell 50.1 / mutter 50.1 on Wayland
Firmware : DMC i915/adls_dmc_ver2_01.bin v2.1
GuC i915/tgl_guc_70.bin v70.49.4
HuC i915/tgl_huc.bin v7.9.3
$ lspci -vnvn -s 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-S
UHD Graphics [8086:a782] (rev 04) (prog-if 00 [VGA controller])
Interrupt: pin A routed to IRQ 137
Kernel driver in use: xe
Kernel modules: i915, xe
Displays
Both attached monitors fail edid-decode --check. In particular the
HDMI-A-1 monitor advertises no DPMS levels at all, and the trigger for
the problem is a DPMS blank/wake cycle.
HDMI-A-1 : EDID vendor EDY, model 9233, name "AF2411", made week 12
of 2026, EDID 1.3, DPMS levels: none
FAIL: sRGB is signaled, but the chromaticities do not match
FAIL: timings out of range of the Monitor Ranges
(28.125-110.000 kHz vs monitor 30.000-115.000 kHz)
HDMI-A-2 : EDID vendor DEL, Dell P2319H, model 53463, made week 47
of 2018, EDID 1.3, DPMS levels: Standby, Suspend, Off
FAIL: missing VCDB in the CTA-861 extension block
FAIL: timings out of range of the Monitor Ranges
Relevant kernel command line
i915.force_probe=!a782 xe.force_probe=a782 xe.enable_fbc=0 xe.enable_psr=0
xe.enable_dsb=0 xe.enable_dc=0
Under this configuration the device binds to xe and the warnings above
still occur, i.e. the parameters above do not suppress them:
i915 0000:00:02.0: I915 probe blocked for Device ID a782.
[drm] Initialized xe 1.1.0 for 0000:00:02.0 on minor 0
Separate issue, already reported elsewhere — NOT this bug
In the same period GNOME Shell also logged, many thousands of times per
boot:
Failed to lock front buffer on /dev/dri/card0:
gbm_surface_lock_front_buffer failed
Failed to query buffer age, got error 3003
Those two lines are the exact subject of bug #2152207, which is a Mesa
(egl-gbm) bug, and are fixed by the Mesa patches shipped in mesa
26.0.8-1ubuntu0.1/0.2/0.3
(egl-gbm-Ignore-current-front-buffer-in-get_back_bo.patch
and related). On this machine they stopped after libgbm1 was upgraded
to 26.0.8-1ubuntu0.3 on 2026-08-22.
The workqueue warnings in this report did NOT stop when that Mesa update
landed. They continued unchanged across that update, which is why I am
reporting this separately against the kernel rather than treating it as
part of #2152207. Please do not close this as a duplicate of #2152207.
Questions
1. Is the poll path being re-armed roughly every 10 s on this dual-HDMI
configuration a known issue, or does it need a fresh trace? Upstream
issue https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14777
has the same warning pair on a Skylake platform and is still open.
2. Is the continuous re-arming consistent with an EDID conformance
problem on either monitor, given that HDMI-A-1 advertises no DPMS
levels? Or is it independent of the monitors?
3. Should Raptor Lake-S [8086:a782] default to xe in this kernel series?
The xe module alias list already covers
pci:v00008086d0000A782sv*sd*bc03sc*i*, so only force_probe is
currently needed to select it.
Happy to run any trace, enable any debug option, or test a patched
kernel. Let me know what you would like.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2167186
Title:
Raptor Lake-S dual HDMI: Intel display hotplug-poll work re-armed
every ~10s indefinitely, hogging CPU (i915_hpd_poll_init_work /
output_poll_execute), on both i915 and xe
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167186/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
