FS#63159 - kernel 5.2: intel i915 modeset (kms) hang at boot
Attached to Project:
Arch Linux
Opened by Riku Salminen (rikusalminen) - Thursday, 11 July 2019, 08:24 GMT
Last edited by Jan de Groot (JGC) - Monday, 16 September 2019, 07:57 GMT
Opened by Riku Salminen (rikusalminen) - Thursday, 11 July 2019, 08:24 GMT
Last edited by Jan de Groot (JGC) - Monday, 16 September 2019, 07:57 GMT
|
Details
Description:
After upgrading to linux-5.2.arch2-1, my Intel graphics (i914) laptop hangs at boot. This occurs as video modes are changing, visible as a change in contrast on the screen. Adding kernel command line `nomodeset` or `i915.modeset=0` will make the system boot normally (without graphics of course). Downgrading to linux-5.1.16-arch1-1 does not have the issue. Additional info: * I do not know if it's only the graphics that is hanging (and the system boots normally otherwise), I haven't tried making contact with the box via network * However, no keyboard input (alt-ctrl-del, etc) makes any difference, so it's probably a hard hang Steps to reproduce: * take Lenovo Laptop with Intel Skylake * Upgrade to linux-5.2-arch2-1 * Reboot system * Observe hang right after rootfs mounted (or at boot if i915 module is added to initrd in mkinitcpio.conf) $ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 08) 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) 00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) 00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21) 00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21) 00:16.3 Serial controller: Intel Corporation Sunrise Point-LP Active Management Technology - SOL (rev 21) 00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1) 00:1c.2 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1) 00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1) 00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21) 00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21) 00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) 00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21) 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-LM (rev 21) 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01) 04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a) 05:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM951/PM951 (rev 01) |
This task depends upon
https://bugs.freedesktop.org/show_bug.cgi?id=111088
The built-in display freezes after some time, sometimes early at boot, sometimes later (it's not deterministic).
Externally connected displays work just fine it's just the built-in display that hangs. That'd explain why enable_psr=0 works.
I have a Dell XPS 13 system affected by some iteration of this.
$ lspci | head -2
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Iris Graphics 540 (rev 0a)
In my case the system boots and works fine, but at some (non predictable) point 1-10 minutes in the display would freeze. The system would not be locked, SSHing in remotely showed no signs of any problems, and even graphical apps could be started / killed from the command line. No Xorg log messages, dmesg, or any other source showed any sign of an error, but the display would be frozen with whatever was drawn at the moment of freeze.
It first manifested on a system update that included the 5.2 kernel and libinput drivers, and for a long time I thought it was related to input devices, then started playing around with video drivers. Interestingly even using the vesa driver and removing xf86-video-intel did not fix this. Downgrading to DRI2 and the fallback uxa acceleration mode seemed to almost fix it but not quite. The freeze just moved to an hour or more out instead of happening in minutes, and in the mean time the performance was abominable.
With the above comments in mind I went back to the intel driver and added i915.enable_psr=0 to my EFI boot options, and wend back to DRI3 + the default acceleration. It's been 30+ minutes with no freeze and normal performance. That hasn't happened in the last several weeks.
The patch is currently in limbo (and user are suffering) because intel devs didn't format their PR properly so it's unlikely to land upstream before weeks.
See https://patchwork.freedesktop.org/patch/319173/?series=63774&rev=4
So arch maintainers should path the kernel themselves until this is fixed upstream. I have been using it for weeks and it works great (I am the "tested-by" tag on the patch).
The patch is not queued for 5.2.7, I would suggest contacting Sasha Levin or Greg Kroah-Hartman to see if the backport is intended to be queued for 5.2.8
possibly by replying to following thread using the instructions included in the thread https://lore.kernel.org/stable/20190731192331.GA17697@sasha-vm/
Edit:
Queued for 5.2.8 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/queue-5.2/drm-i915-vbt-fix-vbt-parsing-for-the-psr-section.patch?id=089bdfa46cf4c8f1b26756a0d6df083c31401fbc