Description of problem: When I boot Fedora 28, my screen does not enable its native resolution. Fedora 27 works. dmesg logs show: [drm:intel_dp_get_link_train_fallback_values [i915]] *ERROR* Link Training Unsuccessful [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled Version-Release number of selected component (if applicable): 4.16.2-300.fc28.x86_64 How reproducible: Intermittent - some boots work and the available resolutions differ between boots. Steps to Reproduce: 1. Boot Fedora 28 2. 3. Actual results: Reduced screen resolution 1280x800 Expected results: Full native screen resolution 1920x1080 Additional info:
Hi Fredrik, I'm assigning this to the Intel driver component as we track video-related bugs there. Does this also fail when you use Fedora 27 with the 4.16.4 kernel currently in updates-testing? It would also be helpful to know if the Rawhide kernel also exhibits this behavior. Thanks!
Jeremy, 4 out of 7 boots still fail with 4.16.4 The error line "LSPCON mode hasn't settled" is repeated 1 to 4 times (and absent in the working 3 boots) so the error is non-deterministic. I'll try to compile 4.17-rc2 tomorrow, it's getting late in CEST. Thanks so far.
The hardware is Intel NUC6I7KYK with a Samsung LC24F396FHUXEN monitor connected over HDMI.
I can reproduce this with the current mainline kernel as of today (4.17-rc2+) in 1 out 5 boots (2 more log the above error but works otherwise). I'm unfortunately unable to compile any old kernels at the moment due to an objtool issue (similar to https://lkml.org/lkml/2018/3/14/1106) so I can not fully conform this as a software regression at the moment.
Kernel 4.14.37 boots to native resolution 11 times consecutively. Kernel 4.14.37 + d18aef0f75436 also boots to native resolution 11 times consecutively with no LSPCON errors in the logs. So this may be a regression.
I'm seeing this issue with an Intel NUC6i7KYB with a AOC U2879VF. Boots up fine, at native resolution, but after leaving the machine for a few minutes after being locked, one display comes back at 1680x1050 as the highest resolution, and cannot be changed higher without rebooting.
Bug still present with 4.17.2-200.fc28.x86_64 and 4.18-rc2
Same issue here. This definitely did not happen with 4.14.20-gentoo and happens nondeterministically with 4.17.2-gentoo.
I've been dealing with this same issue, finally found this thread. This problem seems totally random over a standard HDMI port on Intel Kabylake HD 630 graphics. I have an HP Elitedesk 800 G3 DM with a i7-7700 processor using the HD 630 iGPU. This problem persists across different monitors as well. Sometimes my system will boot in normal resolution 1920x1080 (maybe half the time), others it will boot in stretched 1280x800 or 1650x1050. Still others, I will be unable to boot at all and I just see the error: [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled repeated 1-4 times just as Frederick reported. The non-deterministic behavior doesn't make any sense at all and renders my system borderline unusable. I never once had a problem like this in Fedora 27. Fedora 28 recently started doing this to me within the past month and I haven't the faintest idea why. This is a serious problem, and should be assigned a higher priority/severity. What is going on here?! I can't seem to connect it with a particular kernel version, I've tried the initial Fedora 28 4.16.3 kernel all the way to 4.17.7 and it happens all the same now with packages up to date. This must be a video thing and/or firmware bug, possibly tied to changes in the kernel. I love Fedora, but I simply cannot use it like this.
Bug still present in 4.17.7-200.fc28.x86_64 FWIW, it seems that the problem goes away, or at least is much less likely to show, when I add "nomodeset" to the kernel command line.
Frederick, adding nomodeset to the kernel command line is nowhere close to a solution. The desktop and applications are missing...well most everything the integrated GPU is supposed to handle. Interestingly, I did not experience the weird wrong resolution bug on Intel graphics when I switched to pre-4.16.x kernels like 4.15.17 (built by the Fedora kernel maintainers and available on koji). I think it's safe to say there was a regression somewhere along the way in the transition to 4.16.x on Fedora 28. I should revise my previous post by saying that the HDMI option board on the back of my Elitedesk 800 G3 DM fits a standard HDMI male-to-male cable (no wonky adapters), but it appears that the option board is not in fact a native HDMI connection, as it is recognized by both Windows and Linux as a Displayport despite its physical appearance. When the correct resolution is displayed, xrandr shows the following: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) HDMI-2 disconnected (normal left inverted right x axis y axis) DP-3 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.00*+ 50.00 59.94 1680x1050 59.88 1600x900 60.00 1280x1024 60.02 1440x900 59.90 1280x800 59.91 1280x720 60.00 50.00 59.94 1024x768 70.07 60.00 800x600 72.19 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 66.67 60.00 59.94 720x400 70.08 Maybe that is related somehow? If someone could explain why the part I paid for and installed that is clearly a full-sized HDMI port isn't actually an HDMI connection (notice that DP-3 is the connection), I would be most grateful. I'm beginning to suspect HP got away with creating a janky DP-bus to HDMI/VGA/USBC/DP (varies based on the option board choice) *hardware* motherboard adapter as the rear option board on the Elitedesk 800 G3 DM. In which case I'm inclined to throw what constitutes a $2000 enterprise machine out a window. Somehow, the port works like an HDMI port on Windows and earlier < 4.16.x kernel versions flawlessly. Anyway, HP aside, the following first line always appears a single time in dmesg when the kernel doesn't find the correct resolution of the monitor through the HDMI/DisplayPort connection: [drm:intel_dp_get_link_train_fallback_values [i915]] *ERROR* Link Training Unsuccessful Followed by several error lines of good ol' [drm:lspcon_wait_mode [i915]] *ERROR* LSPCON mode hasn't settled Basically, the kernel isn't correctly setting full HD resolution of the monitor around *half* the time. Booting Fedora 28 on my machine with Intel graphics is like tossing a die: I either get Full HD, variants of stretched and incorrect low resolution, or (rarely, but still) failure to boot at all. The fact this *doesn't* appear to happen on other distributions with kernel >=4.16.x indicates that something seriously weird is going on with Fedora patches to the mainline kernel. That, or it really is a major problem with Intel video drivers and related packages like xorg-x11-drv-intel. This issue is fairly critical, and I have no other choice but to use a different distribution on enterprise 'certified' Linux-compatible hardware until this issue is resolved.
Welp, I stand corrected. This exact same bug is fully reproducible on Ubuntu and Debian-testing running kernel 4.17.7, but cannot be reproduced on kernels before 4.16.x. Here is the output I receive on a 'bad boot' from xrandr (it should show the 1080p modeline as given above). Screen 0: minimum 320 x 200, current 1280 x 800, maximum 8192 x 8192 DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) HDMI-2 disconnected (normal left inverted right x axis y axis) DP-3 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1280x800 59.91* 1024x768 60.00 800x600 72.19 60.32 56.25 720x576 50.00 720x480 60.00 59.94 640x480 66.67 60.00 59.94 720x400 70.08 This is *definitely* a Linux kernel regression in regard to the Intel graphics stack (in my case the Kabylake HD 630 iGPU), and not unique to Fedora at all. Not sure whether Intel's changes are directly at fault or if this is some weird byproduct/combination of graphics stack changes and the getrandom/csprng kernel changes in the 4.16.x+ tree. This bug should probably be referenced on Launchpad and the kernel Bugzilla as well then.
In particular, 1280x1800 and 1680x1050 (made a little typo above) are the two resolutions I find myself limited to when the kernel boots and doesn't correctly display the full 1920x1080 native resolution of the monitor (in this case, a Samsung CF591). This issue does not, however, appear related to this particular monitor as two others I have tried (two radically different HP monitors) end up with the same issue. Nor is it a cable problem, I switched that out several times as well. After much testing, the issue seems very non-deterministic indeed. Grub and Plymouth don't appear to be culprits either, at least not unless the kernel is unduly influencing the correct selected resolution during boot, in which case something here reminds me of this particular bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572
Read up on LSPCon [1]. This is a hack Intel came up with to support HDMI 2.0, which the CPU/chipset do not support natively. It is indeed an external DisplayPort to HDMI protocol converter. It is required on all Skylake/Kaby Lake (and some later?) platforms that want to support HDMI 2.0. This is why the output shows up as DisplayPort. There is a regression related to LSPCon support somewhere in 4.17. [1] https://www.anandtech.com/show/9562/intels-skylake-gpu-analyzing-the-media-capabilities
Hector, thank you very much. I found a good little summary of just that, and I suppose it does make sense. I was worried it might be an odd proprietary thing on my motherboard, but it is just as you described. I should stress, however, that it is not an adapter in the sense it dangles off the back of a DisplayPort. Rather, it is a full size HDMI port on a mini logic board connected to motherboard itself that sits flush with the rear IO plate. It uses the LSPCON protocol as you described, which is honestly a relief, but this does strike me as quite a "hack" indeed, albeit a hardware one. From Intel i915 dev Imre Deak: "There are two ways to connect HDMI to the APL RVPs: via the DDI1 DP++ plug with an DP->HDMI dongle, or via the DDI0 HDMI plug which is connected to the SoC through the LSPCON converter. You seem to be using the second scenario with LSPCON being in the protocol converter mode (configured as such by BIOS). In that case the connection will show up as a DP connector." It appears that LSPCON handling through the kernel and associated Intel Skylake and Kabylake graphics stack is definitely the culprit here.
I have filed a corresponding kernel bug report here, as this issue affects more than just Fedora users and constitutes a kernel regression: https://bugs.freedesktop.org/show_bug.cgi?id=107503 If anyone affected could please contribute there, I would appreciate it.
Huh, after 4.17.7 I cannot replicate the problem. 4.18-rc8 as well as drm-tip (built from today 08/09) are both okay. I rebooted repeatedly selecting drm-tip for around half an hour (seriously) and not a single instance did this strange screen-resolution issue occur. Bisecting the kernel should no longer be necessary, it appears the problem is resolved in drm-tip and the latest release candidate build of 4.18. I believe this issue should be marked as resolved for now. If anyone manages to replicate the bug in drm-tip or in the latest rc kernel, please provide Imre Deak on https://bugs.freedesktop.org/show_bug.cgi?id=107503 with a full dmesg log from boot with the "drm.debug=0x1e log_buf_len=10M" kernel parameters.
This is still broken for me both on 4.17.11-200.fc28 and 4.18.0-rc8+ (112cbae2) I am not able to reproduce it with drm.debug=0x1e. But I have the dmesg if you still have use for it.
Bug still present on drm-tip as of today (da34c4841d4b)
Fredrik, using that kernel parameter drm.debug=0x1e is necessary so the Intel devs can actually see what's going wrong. I have been able to get a full dmesg from boot on 4.17.7 using this parameter, but I cannot reproduce the bug using the necessary debugging parameter afterwards on drm-tip or on 4.18-rc8. The parameter log_buf_len=10M is necessary to increase the size of the kernel dmesg buffer so you can actually get the critical first pieces with all the extra Intel debugging details. I will reopen https://bugs.freedesktop.org/show_bug.cgi?id=107503 , please provide the Intel graphics developer with the full dmesg from boot that you have. Perhaps it's hardware specific or affected by adding the drm debug paramter?
If the issue is timing-related (which is quite likely given the randomness and the error message associated with it) then it's quite possible that enabling additional debugging might slow things down enough to stop it from happening.
(In reply to Hector Martin from comment #21) > If the issue is timing-related (which is quite likely given the randomness > and the error message associated with it) then it's quite possible that > enabling additional debugging might slow things down enough to stop it from > happening. Yes, this very well might be a timing related bug, as the drm.debug=0x1e parameter writes hundreds of lines of feedback to the kernel log quickly. I can confirm this bug is very much indeed still a problem. I have posted my dmesg sans the debugging parameter as well as the output of xrandr --verbose from a good and bad boot on the Intel graphics bug thread https://bugs.freedesktop.org/show_bug.cgi?id=107503. The bug is *very* reproducible without adding any extra kernel parameters on Fedora 28 and Ubuntu 18.04. Please contribute there, as that is where the Intel graphics devs can actually address this issue.
Okay, I can confirm that this bug exists on and started with 4.16-rc1, and cannot be replicated with the any of the 4.15 series up to and including 4.15.18. I'm afraid I cannot pinpoint what exactly went wrong between 4.15.x and 4.16-rc1, as the sheer volume of changes for the first release candidate build alone are massive. I would appreciate if someone could assist and look into this further, as it does constitute a major blocking-level problem and remains present even on drm-tip. I firmly believe this is a kernel-level issue related to changes in the 4.16 tree. If we are lucky, it could be something wrong in the i915 module. Otherwise, it could be a nasty side effect of other changes beginning with the first release candidate build of 4.16. Furthermore, this issue persists across different Linux distributions with different packages to the point where I think labeling the bug as belonging to "xorg-x11-drv-intel" is incorrect. This is also not a "quality assurance" issue on Fedora specifically, it's far more endemic than that. Bisecting this issue is totally beyond my capabilities. Furthermore, the bug I filed at https://bugs.freedesktop.org/show_bug.cgi?id=107503 is where this discussion belongs as the problem is on the DRM Kernel level. As such, I believe this bug requires intervention from the assignee.
Created attachment 1475374 [details] Add a retry loop to lspcon_wait_mode Patch attached. It probably needs both testing and polish, but it seems to work for me.
In summary: The LSPCON converter occasionally needs time to settle down during driver loads. This has been a cause of several bug reports, four of which were patched in 4.15 with commit f687e25a7a24 drm: Add retries for lspcon mode detection In this case, however, it seems that the not-yet-settled LSPCON device returns a technically valid, but unexpected mode, thus never triggering the retry loop added in the patch above. Adding a second retry loop directly in lspcon_wait_mode gives the converter the time needed to settle. With the patch above, I still get occasional errors, but the retry attempts are successful and all modes are eventually enumerated. The DRM_ERROR message should therefore probably be downgraded to DRM_DEBUG_KMS, with a DRM_ERROR logged only when the entire retry loop fails. The apparent regression from 4.15 is probably a seemingly unrelated change that effects the timing and triggers this bug.
Created attachment 1475389 [details] Increase timeout in lspcon_wait_mode So I overlooked this much simpler fix. 7/7 boots OK, no errors logged.
Patch merged as of kernel-4.18.8-200.fc28
4.18.14-200.fc28.x86_64 still showing this issue with xorg-x11-drv-intel.x86_64 2.99.917-32.20171025.fc28. system boots (in xorg, not wayland) fine and in 1080p resolution, but after screen blank, monitor shows max resolution to 1024x768. CRTC info --------- CRTC 39: pipe: A, active=yes, (size=1024x768), dither=yes, bpp=18 fb: 67, pos: 0x0, size: 1024x768 encoder 59: type: DP C, connectors: connector 60: type: DP-1, status: connected, mode: id 0:"" freq 0 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x0 flags 0xa cursor visible? no, position (0, 0), size 0x0, addr 0x00000000 No scalers available on this platform --Plane id 28: type=PRI, crtc_pos= 0x 0, crtc_size=1024x 768, src_pos=0.0000x0.0000, src_size=1024.0000x768.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001) --Plane id 31: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001) --Plane id 36: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001) underrun reporting: cpu=yes pch=yes CRTC 51: pipe: B, active=no, (size=0x0), dither=no, bpp=0 underrun reporting: cpu=yes pch=yes Connector info -------------- connector 52: type VGA-1, status: disconnected modes: connector 55: type HDMI-A-1, status: disconnected audio support: no modes: connector 60: type DP-1, status: connected name: physical dimensions: 510x290mm subpixel order: Unknown CEA rev: 3 DPCD rev: 11 audio support: yes DP branch device present: no modes: id 82:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x40 flags 0xa id 83:"800x600" freq 75 clock 49500 hdisp 800 hss 816 hse 896 htot 1056 vdisp 600 vss 601 vse 604 vtot 625 type 0x40 flags 0x5 id 84:"800x600" freq 72 clock 50000 hdisp 800 hss 856 hse 976 htot 1040 vdisp 600 vss 637 vse 643 vtot 666 type 0x40 flags 0x5 id 74:"800x600" freq 60 clock 40000 hdisp 800 hss 840 hse 968 htot 1056 vdisp 600 vss 601 vse 605 vtot 628 type 0x40 flags 0x5 id 66:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796 htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa id 93:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796 htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa id 94:"720x576" freq 50 clock 27000 hdisp 720 hss 732 hse 796 htot 864 vdisp 576 vss 581 vse 586 vtot 625 type 0x40 flags 0xa id 100:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798 htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa id 104:"720x480" freq 60 clock 27027 hdisp 720 hss 736 hse 798 htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa id 65:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798 htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa id 86:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798 htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa id 87:"720x480" freq 60 clock 27000 hdisp 720 hss 736 hse 798 htot 858 vdisp 480 vss 489 vse 495 vtot 525 type 0x40 flags 0xa id 75:"640x480" freq 75 clock 31500 hdisp 640 hss 656 hse 720 htot 840 vdisp 480 vss 481 vse 484 vtot 500 type 0x40 flags 0xa id 76:"640x480" freq 73 clock 31500 hdisp 640 hss 664 hse 704 htot 832 vdisp 480 vss 489 vse 492 vtot 520 type 0x40 flags 0xa id 101:"640x480" freq 60 clock 25200 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa id 77:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa id 85:"640x480" freq 60 clock 25175 hdisp 640 hss 656 hse 752 htot 800 vdisp 480 vss 490 vse 492 vtot 525 type 0x40 flags 0xa id 78:"720x400" freq 70 clock 28320 hdisp 720 hss 738 hse 846 htot 900 vdisp 400 vss 412 vse 414 vtot 449 type 0x40 flags 0x6
TJ, Could you please confirm with dmesg | grep LSPCON and preferably also with the stress test in https://bugs.freedesktop.org/show_bug.cgi?id=107503#c21 that you are seeing the same bug as I did. If so, does increasing the timeout to 1000ms with the patch in https://bugzilla.redhat.com/attachment.cgi?id=1475389 help? We eventually settled on 400 ms as it seemed long enough.
[root@hostname /]# dmesg | grep LSPCON [root@hostname /]# [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Full" [root@hostname /]# xrandr | wc -l 10 [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Automatic" [root@hostname /]# xrandr | wc -l 10 [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Full" [root@hostname /]# xrandr | wc -l 10 [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Automatic" [root@hostname /]# xrandr | wc -l 10 [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Full" [root@hostname /]# xrandr | wc -l 10 [root@hostname /]# xrandr --output DP-1 --set "Broadcast RGB" "Automatic" [root@hostname /]# xrandr | wc -l Where exactly does one apply this patch? Do i need to make the i915 intel driver from source so i can access this file? /drivers/gpu/drm/i915/intel_lspcon.c currently just using the package xorg-x11-drv-intel.x86_64
It is possible that you are seeing an independent bug. I would have expected "*ERROR* LSPCON mode hasn't settled" messages in your kernel logs, and dropped modes when toggling xrandr settings. The patch is against the Linux kernel tree, and you will have to build your own kernel to test it. As the patch is based on v4.18.0, it also won't apply cleanly to 4.18.14 or current mainline but it should be trivial to adapt.
I am running CENTOS 7 and encountering the same problem. My hardware is a Zotac zbox ci547 containing an Intel Kaby Lake core I5 cpu with Intel HD graphics 620. Up until kernel version 3.10.0-862 things worked fine. Since the kernel was update to version 3.10.0-957 I encounter the problem described in this bug report. Looking at the kernel sources I see that the LSPCON timeout was set to 100 in version 3.10.0-862 and things worked just fine. So I wonder why a change became necessary in version 3.10.0-957. Anyway, I would like to see an appropriate patch be applied in the kernel versions supplied to CENTOS 7 via the update command, since many users (including me) are unable/unwilling to supply patches and build their own kernels. Is this the right place to trigger such a change? Best regards, Lars
Same here with Arch Linux, 5.0.13-arch1-1-ARCH and same hardware as Lars. Most of the times DP gets 1080p and HDMI gets 1024x768 only. There is no line in dmesg complaining about LSPCON, but when system doesn't find screens correct resolutions, there are at least two lines of [drm:intel_dp_get_link_train_fallback_values [i915]] *ERROR* Link Training Unsuccessful I tried the patch from above but it hasn't helped. Looks like an independent bug indeed.