NOTE: I received an email from Ian Pilcher through users@lists.fedoraproject.org saying = Intel broke multi-stream transport in 4.15/4.14.4: https://bugs.freedesktop.org/show_bug.cgi?id=104425 https://bugs.freedesktop.org/show_bug.cgi?id=104158 ------ My original issue/bug = I had a working Fedora 24 box for almost 2 years that I decided to upgrade to FC 27. I have 3 monitors and used a 3 way adapter from StarTech to adapt the single display port from my Intel NUC to support my 3 displays. Again this worked fine for years. After the upgrade this setup stopped working. My system has an encrypted root and home partition, and an un-encrypted boot partition. When I power on the computer with the 3 way adapter I get bios screens and the grub menu. If I select the old FC24 kernel to boot, the system proceeds to the password screen where I unlock my root partition, and then to the user login screen for fedora. But if I select one of the new FC 27 kernels on the grub menu I get a black screen only, no password screen to un-encrypt. If I use a straight through DisplayPort cable to power only one screen, the new Kernels work fine and I can unlock and login. Also, adding *nomodeset* to the kernel boot options will allow the new kernels to work with the adapter, but all 3 screens mirror and performance is way down. I think this option doesn't use Intel's drivers? I looked at Xorg vs Wayland as a possible cause, but the option to select that is on the user login screen, would that have any effect on the un-encrypt password screen just after grub? My graphics are Intel Iris 6100. My hardware is an Intel NUC with i7 processor. Video card is on chip. So I am stuck. Please help? ***** I made sure my Intel drivers where fully updated = $ sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm Last metadata expiration check: 0:59:03 ago on Tue 16 Jan 2018 09:22:40 PM CST. rpmfusion-free-release-27.noarch.rpm 24 kB/s | 20 kB 00:00 Package rpmfusion-free-release-27-1.noarch is already installed, skipping. Dependencies resolved. Nothing to do. Complete! $ sudo dnf install intel-gpu-tools libva-intel-driver libva-utils libva mesa-libOSMesa cairo-gobject cairo mesa-dri-drivers mesa-filesystem mesa-libEGL mesa-libGL mesa-libGLES mesa-libgbm mesa-libglapi mesa-libwayland-egl mesa-libxatracker Last metadata expiration check: 0:59:23 ago on Tue 16 Jan 2018 09:22:40 PM CST. Package intel-gpu-tools-2.99.917-31.20171025.fc27.x86_64 is already installed, skipping. Package libva-intel-driver-1.8.3-2.fc27.x86_64 is already installed, skipping. Package libva-intel-driver-1.8.3-2.fc27.i686 is already installed, skipping. Package libva-utils-1.8.3-4.fc27.x86_64 is already installed, skipping. Package libva-1.8.3-3.fc27.x86_64 is already installed, skipping. Package libva-1.8.3-3.fc27.i686 is already installed, skipping. Package mesa-libOSMesa-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libOSMesa-17.2.4-2.fc27.i686 is already installed, skipping. Package cairo-gobject-1.15.10-1.fc27.x86_64 is already installed, skipping. Package cairo-gobject-1.15.10-1.fc27.i686 is already installed, skipping. Package cairo-1.15.10-1.fc27.x86_64 is already installed, skipping. Package cairo-1.15.10-1.fc27.i686 is already installed, skipping. Package mesa-dri-drivers-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-dri-drivers-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-filesystem-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-filesystem-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libEGL-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libEGL-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libGL-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libGL-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libGLES-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libgbm-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libgbm-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libglapi-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libglapi-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libwayland-egl-17.2.4-2.fc27.x86_64 is already installed, skipping. Package mesa-libwayland-egl-17.2.4-2.fc27.i686 is already installed, skipping. Package mesa-libxatracker-17.2.4-2.fc27.x86_64 is already installed, skipping. Dependencies resolved. Nothing to do. Complete!
Hello, could you please attach dmesg logs from the functional and not functional kernels with debug information, drm.debug=0x1e log_bug_len=2M(or bigger as needed) parameters on grub?
Created attachment 137630 [details] Result of 'drm.debug=0x1e' from working FC24 kernel
I have now attached the log file you requested from the 'functional' kernel bootup. I am sorry, but you are working with a bit of a newbie here. You asked for the same from the non-functional kernels, but because the system hangs when booting those with the adapter attached (and a hard shutdown is required to regain system control) I do not know how to get a dmesg log of that boot-up. A bit of a walk-through of how to do it would be helpful.
If you use systemd, the messages from dmesg are also stored within the journald. So you should have a look at journalctl --list-boots and then on something like journalctl -b (boot id)
Created attachment 137743 [details] journalctl OK, so i booted the PC in normal mode using a good kernal, then powered down and tried to boot the system 2 times with the new kernels, then booted with the older one again and ran the following command = journalctl --since yesterday >fedora_error.txt I don't think it gave the output your looking for. Both times I tried the new kernel boots i put in the line 'drm.debug=0x1e log_bug_len-2M'
Sorry, should have been = 'drm.debug=0x1e log_bug_len=2M' Promise I typed it right in the boot options.
You can try to get it by ssh or using a script.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
(In reply to Jani Saarinen from comment #8) The bug is still valid, yes, the problem still occurs. But I am unable to supply the requested information. I do not know how to get the logs they are requesting. In fact, since the kernel and logging system is locked in the encrypted partition and the system fails to unlock that partition before freezing, I don't think any journalctl logs exist for the failed boot attempts. But as I said I am a newbie to linux, so I could be wrong. But I will need more instruction to get the requested information.
There has been MST related changes on https://cgit.freedesktop.org/drm-tip lately. Can you build / try that?
(In reply to Jani Saarinen from comment #10) > There has been MST related changes on https://cgit.freedesktop.org/drm-tip > lately. > Can you build / try that? I have formatted that PC and moved to a different OS. You may close my bug report. Thank you for trying to assist with this issue.
OK, thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.