Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#57348 - [linux-lts] Screen blanking regression in LTS 4.14.16-1

Attached to Project: Arch Linux
Opened by Chuck (foxcm2000) - Saturday, 03 February 2018, 02:28 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 March 2018, 13:39 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



I have a Lenovo Thinkpad Helix 2 that is using a Broadwell Core-m processor with a 1920x1080@60Hz display.

The machine booted and ran fine using the old 4.9 series LTS with no special settings.

However, something has gone seriously wrong with the new 4.14.16-1 LTS kernel because without extreme kernel command line and i915 module hacking the screen completely blacks out just a few seconds into the boot process and will never display anything until rebooting. The machine itself is finishing the boot sequence and I can login via SSH, but the display never produces output.

After extensive hacking I have managed to get the machine to boot to a command line using the following options:

The kernel command line in grub.cfg:

linux /boot/vmlinuz-linux-lts root=UUID=8b8cab89-1cc0-4263-b29b-010c7ecfbf0b rw quiet video=eDP-1:1920x1080@60

The following i915 module options in /etc/modprobe.d/i915.conf:

options i915 modeset=1 enable_execlists=0 enable_rc6=0

However, this *only* gets me to a command line. Any and every attempt to start the X server bombs out with this error:

(EE) no screens found(EE)

Here's my theory: Something has gone wrong in the kernel where KMS is somehow no longer able to get the edid information out of the display to set the modes for graphics. This simple process appeared to work perfectly in kernel 4.9 but has fallen off a cliff somewhere along the line in getting to kernel 4.14.

I have experimented with "read-edid" and all I can tell is that it tries to get edid information and then hangs when I run it.

Note: The real root of this bug is *below* the level of Xorg. I have even disabled the X server to confirm that the bug manifests even if the system would only boot to a command prompt. Right now after manually hacking the mode at the command line I can get a command prompt, but that is just masking whatever bug is in the kernel.

Steps to reproduce:

Install linux-lts 4.14.16 and boot a Lenovo Helix 2 using the exact same configuration that worked fine in linux-lts 4.9.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Wednesday, 21 March 2018, 13:39 GMT
Reason for closing:  No response
Comment by Chuck (foxcm2000) - Saturday, 03 February 2018, 02:50 GMT
Incidentally, I saw this bug:

I might be hitting the same bug. However, this notebook does not have any option to turn on "CSM" mode since it only supports UEFI. Fixing the bug instead of requiring firmware hacks is desirable anyway, especially since this hardware used to work perfectly fine.
Comment by Andreas Radke (AndyRTR) - Saturday, 03 February 2018, 07:39 GMT
I'm pretty sure we haven't touched the kernel config in that area. So please work with upstream to solved such a regression.
Comment by loqs (loqs) - Saturday, 03 February 2018, 08:58 GMT
Please bisect the kernel between 4.9 and 4.14 to find the bad commit. Please start a forum thread if you need help with performing the bisection.
Comment by Chuck (foxcm2000) - Saturday, 10 February 2018, 01:35 GMT
Sorry for the delay but I don't have a huge amount of time to do deep debugs.

I didn't run the kernel bisect since doing a massive GIT checkout and massive compile runs on a two-core ultramobile device isn't within my time resources.

However, I do know the exact point where the official Arch packages failed: linux-4.13-1-i686.pkg.tar.xz [the first package in the 4.13 series] is the first version that fails to modeset the screen and linux-4.12.8-2-x86_64.pkg.tar.xz [the final package in the 4.12 series] was the last version that worked fine.

Basically, starting with 4.13 there's a nasty bug that got introduced and apparently hasn't been fixed in the mainline kernel.
Comment by loqs (loqs) - Saturday, 10 February 2018, 12:57 GMT
Report it upstream supplying as much of the requested information as you can