FS#57348 - [linux-lts] Screen blanking regression in LTS 4.14.16-1
Attached to Project:
Arch Linux
Opened by Curtis (foxcm2000) - Saturday, 03 February 2018, 02:28 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 March 2018, 13:39 GMT
Opened by Curtis (foxcm2000) - Saturday, 03 February 2018, 02:28 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 21 March 2018, 13:39 GMT
|
Details
Description:
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
Wednesday, 21 March 2018, 13:39 GMT
Reason for closing: No response
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.
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.