i915 regression introduced with 5.5 kernel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Fix Released
|
Unknown
|
|||
linux (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Focal |
Invalid
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Medium
|
Unassigned | ||
Mantic |
Fix Released
|
Medium
|
Unassigned | ||
Noble |
Fix Released
|
Medium
|
Unassigned | ||
linux-hwe-5.15 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Medium
|
Unassigned | ||
Jammy |
Invalid
|
Undecided
|
Unassigned | ||
Mantic |
Invalid
|
Undecided
|
Unassigned | ||
Noble |
Invalid
|
Undecided
|
Unassigned |
Bug Description
[ Impact ]
Commit 8f4b1068e7fc3df
After going through bisection between 5.4 and 5.5 this commit was identified. Reverting it on top of Focal HWE kernel fixes the issue.
The issue has been addressed upstream in DRM tree (20c2dbff342aec
dmesg and lspci from the affected configuration are attached to this bug.
[ Test Plan ]
1. Boot the affected hardware with Ubuntu desktop running kernel v5.5 or higher.
2. Wait until boot finishes and see the blank screen.
Actual result: there is no video output visible.
Expected result: normal boot process should be visible (e.g. splash), then GUI should appear.
[ Where problem could occur ]
This bug was a result of assumptions in the checks that turned out to be not valid for some hardware. The checks were removed from global intel_mode_valid function and moved into connector specific .mode_valid() hooks, entirely skiping BXT/GLK DSI connectors.
This should keep the checks where appropriate and skip for hardware that does not comply to them.
[ Other info ]
Original bug description:
There is a regression preventing a user to upgrade from 5.4 kernel to anything that's higher than 5.5. When using such kernel the image orientation is wrong (rotated by 90°C). Also the kernel log contains:
wrz 15 09:19:49 desktop kernel: i915 0000:00:02.0: [drm] Unknown revid 0x06
wrz 15 09:19:49 desktop kernel: rtw_8821ce 0000:01:00.0: Firmware version 24.8.0, H2C version 12
wrz 15 09:19:49 desktop kernel: Console: switching to colour dummy device 80x25
wrz 15 09:19:49 desktop kernel: i915 0000:00:02.0: vgaarb: deactivate vga console
wrz 15 09:19:49 desktop kernel: i915 0000:00:02.0: [drm] couldn't get memory information
wrz 15 09:19:49 desktop kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=
wrz 15 09:19:49 desktop kernel: i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/glk_
wrz 15 09:19:49 desktop kernel: =======
wrz 15 09:19:49 desktop kernel: UBSAN: array-index-
wrz 15 09:19:49 desktop kernel: index 5 is out of range for type 'u32 [5]'
(full stack trace attached)
The video hardware in use is:
00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3185] (rev 06) (prog-if 00 [VGA controller])
(...)
Kernel driver in use: i915
Kernel modules: i915
The user wanted to upgrade from bionic to focal with HWE kernel (they needed it due to some networking hardware they wanted to have supported by the newer kernel).
The user was testing mainline stable kernels and noticed that the last working kernel was the 5.4 series, while anything starting from 5.5 and above is BROKEN (symptoms as described in the first paragraph above).
Together with the user we have run a bisection between v5.4 and v5.5 on the upstream stable kernel and we were able to identify the first broken commit to be:
8f4b1068e7fc3df
To confirm I have reverted this change on top of the HWE kernel for focal and the user have confirmed that this resolved the issue (test build available at ppa:dgadomski/
I am not fully sure what the purpose of this patch was, but I assume the regression was not intended and the hardware should be still supported.
Attaching lshw and lspci output.
Changed in linux: | |
status: | Unknown → Fix Released |
tags: | added: patch |
The commit in question (8f4b1068e7fc3d f1a77ac8151767e 56b208cc87f) introduces the following logic in intel_mode_valid function (drivers/ gpu/drm/ i915/display/ intel_display. c):
+ if (DISPLAY_ VER(dev_ priv) >= 5) {
+ if (mode->hdisplay < 64 ||
+ mode->htotal - mode->hdisplay < 32)
+ return MODE_H_ILLEGAL;
+
+ if (mode->vtotal - mode->vdisplay < 5)
+ return MODE_V_ILLEGAL;
+ } else {
+ if (mode->htotal - mode->hdisplay < 32)
+ return MODE_H_ILLEGAL;
+
+ if (mode->vtotal - mode->vdisplay < 3)
+ return MODE_V_ILLEGAL;
+ }
In case of this particular hardware the following condition is met:
if (mode->htotal - mode->hdisplay < 32)
return MODE_H_ILLEGAL;
with values: htotal==830 and hdisplay=800 resulting in returning MODE_H_ILLEGAL.
I am looking into where does the htotal value come from.