Description of problem: Graphics don't work when booting docked with DVI-D monitor attached. When I boot undocked, graphics work. My HD is LUKS encrypted. The LUKS prompt comes up in 80-column ASCII when it's not working, and 3 boxes seem to indicate some status. The system doesn't actually boot when "graphics don't work." Version-Release number of selected component (if applicable): 4.14.6-300.fc27.x86_64 (kernel-4.13.16-302.fc27.x86_64 works) How reproducible: Boot docked Steps to Reproduce: 1. Get a ThinkPad P50 with NVIDIA Corporation GM107GLM [Quadro M1000M] (rev a2) 2. Install F27 with kernel-4.14.6-300.fc27.x86_64 3. Dock 4. Boot Actual results: The LUKS prompt comes up in 80-column ASCII, and entering the password doesn't actually get the system to boot. Escape during the 3 boxes status display shows that it's stuck during the boot process a few steps along in the boot process. Expected results: The LUKS prompt comes up in the usual GUI box and the system boots after. Additional information: Booting undocked and then docking now makes the external display work, which is a step in the right direction.
*** Bug 1528041 has been marked as a duplicate of this bug. ***
I'd recommend testing a rawhide kernel to see if the problem has been fixed there. Failing that, your best bet is probably to run a kernel bisect.
I have a similar issue but with display port attached monitors. Booting undocked and then docking does not work. The hang was observed as the standard "Reached Target Basic System" but I couldn't get any more debug. I observed the issue in both discrete and hybrid graphics modes.
P50, Dock and two external monitors connected via DVI and Diplayport. BIOS is set to discrete graphics only (nouveau driver used) I noticed the same issue: Starting with kernel 4.14 I cannot boot anymore. The system does not show a graphic luks password, just plain text. After entering the password the system is dead. Today I was able to boot with monitors unplugged. Once GDM showed the login screen I plugged the monitors - no change yet. On logon to gnome the monitors were detected and used.
Yes, the latest rawhide kernel (4.15.0-0.rc6.git0.1.fc28) seems to help. Few notes though: * I run Fedora 26 * I boot without rhgb * my systemd default target is multi-user * there were several "pauses" during the start up which I don't observe with older kernels (4.12); "systemd-analyze blame" hints: 42.723s plymouth-quit-wait.service 20.232s plymouth-quit.service 14.710s colord.service These services start in less than 25ms on 4.12 kernels.
I believe I have been able to boot VGA+DVI and use both monitors successfully very recently, of course once I undock, I can't then redock and have the monitors be picked up.
I tested the Rawhide No Debug kernel using the repo here: https://fedoraproject.org/wiki/RawhideKernelNodebug I see the same broken behaviour in that Rawhide kernel (on my update to date F27 userland) as we do in 4.14. I'm unlikely to do the kernel bisect any time soon I've never attempted it before - Is this the current best process: https://pagure.io/fedbisect For the moment I'm continuing to run 4.13
I am running into the same issue on Fedora 27 on a Lenovo P50. I currently have the 4.15.0 kernel installed, and am able to boot the laptop when it's not in the dock, and then, once it fully boots up, I can place the laptop back in the dock and the attached monitors will be recognized and begin to work. It's nice to know this is the problem, and can be worked around in the above fashion, because I had reverted to 4.13.x for several weeks, hoping for a fix in 4.14.x, which never arrived.
It is possible that you are encountering the same issue I added comments on here: https://bugs.freedesktop.org/show_bug.cgi?id=103721 I can say that if we are experiencing the same problem as me, it's still an issue in 4.14.15 (https://bodhi.fedoraproject.org/updates/FEDORA-2018-0b4c4e1fed - if you click bugs, you'll see one different nouveau bug is fixed at least.) A way to see if this is the same issue is to edit your grub line on startup, preferably choosing the debug kernel. Remove the "quiet rhgb" and press ctrl+x to boot. Very soon you should see kernel message output similar to what I attached to the freedesktop bug above in my first attachment (scroll up and down with shift+page up/down).
This may be the same as bug 1509294.
I can still reproduce the exact same behaviour on 4.14.18. The only way to get around this problem seems to be using 4.13.x. Docking in the P50 after it booted successfully is not an option for me, because external monitors are still not recognized reliably (https://bugzilla.redhat.com/show_bug.cgi?id=1477182).
I am still seeing this issue with 4.15.3.
As I still suffer from the same issue, I tried bisecting the kernel using fedbisect, but unfortunately failed (see https://pagure.io/fedbisect/issue/3 for details). But here are some more observations I made on Fedora 26. For all of them, I have set the graphics mode to Hybrid, unless noted otherwise. kernel-4.13.16-200.fc26 boots without issues. kernel-4.14.4-200.fc26 fails to boot kernel-4.15.3-200.fc26 fails to boot kernel-4.14.18-200.fc26 has a success rate of about 50-70%. Waiting a little longer than 5 seconds in the grub menu seems to improve chances. Setting graphics mode to Discrete in BIOS means I can't boot at all any more using kernel-4.14.18-200.fc26. All this is done using the nouveau drivers. Installing proprietary nvidia graphics drivers from rpmfusion means I can boot all the times, even with kernel-4.15.3-200.fc26. I tried to get some logging data by following this: https://fedoraproject.org/wiki/Kernel/EarlyDebugging But this results in a long waiting time, followed by some quick log messages and then the screen turns black (LCD backlight is still on). So no success. I'm willing to run a kernel bisect again, but I need help on that.
4.15.4-300.fc27.x86_64 fails to boot.
Yeah the fedbisect scripts are mostly abandoned because it turned out not to be that much better than building in tree. You are better off just bisecting on the kernel tree directly.
Also experiencing this issue, but have not attempted diagnostics.
Still no luck with 4.15.10-300.fc27.x86_64.
*** Bug 1535587 has been marked as a duplicate of this bug. ***
I figured out, that I can boot while docked with kernel 4.15.14-200.fc26.x86_64 iff there is no external display connected to the docking station. This applies to DP and DVI connections. I haven't tried other connections or other kernel versions. Other than that, I tried bisecting the issue, but I need help clarifying some oddities. https://fedoraproject.org/wiki/Building_a_custom_kernel describes several ways of building your own kernel for fedora. But in some ways, they don't generate the same results, and so I need help figuring out what the difference is. Following the description "Building a Kernel from the Fedora source tree", I ran the following: fedpkg clone -a kernel git checkout -b bisect 9457eae4a046ca1f467b5ccc95ca10868de51224 // refers to the last commit on f26 containing a 4.14.4 kernel defined buildid in kernel.spec fedpkg local installed kernel, kernel-core and kernel-modules This resulted in a kernel that contained this bug (screen turns and stays black just before LUKS prompt is about to show up). I then followed the description "Building a kernel from the exploded git trees" in order to bisect. So I ran: git clone git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git git checkout -b bisect kernel-4.14.4-200.fc26 // git commit 30760ce6098b431e1424e3f5c28084415c750749 modify Makefile to edit EXTRAVERSION copy config from the kernel built by fedpkg make oldconfig make bzImage make modules make modules_install make install This resulted in a kernel NOT suffering from this bug. So can anybody tell me how I can easily find the difference between these two kernels? Thanks in advance.
There shouldn't be any code differences. The jwboyer tree is supposed to be the same code with all the patches applied as the rpms/kernel.git tree. I'm not a kernel developer, so perhaps I'm confused - see what you make of this: $ git checkout -b fedora-rpm 9457eae4a046ca1f467b5ccc95ca10868de51224 $ fedpkg --release f26 prep This step will download the sources and then apply all the patches, along with adding a directory containing the vanilla source. Compare to your checkout of jwboyer/fedora.git at 30760ce6098b431e1424e3f5c28084415c750749. The only differences I found were a bunch of missing .gitignore files and a few helper scripts in the root of the tree. If you're able to consistently rebuild at what appears to be comparable SHAs and have one exhibit the problem and the other not, this may not be an upstream kernel issue. But I'm only guessing based on the identical source code.
FWIW, this is probably now a blocker for us to migrate to f28
On a side note: the problem does not occur with the binary driver, which is now available in the proprietary repository (see: https://fedoramagazine.org/third-party-repositories-fedora/). That said, I'd rather be able to use the open source driver than being forced to use the binary NVIDIA driver from now on. Did we get any closer to identify the kernel patch which caused the issue? Daniel seems to be very close to the issue's root problem.
I built kernel 4.14.4-200.fc26 from scratch both using fedpkg and from jwboyer tree (see list of commands below). The code is the same for all practical purposes. However, the kernels do not behave the same. I tested it by docking my laptop, power it on, select the right kernel in the grub menu, wait until LUKS prompt appears (or not), power it off (by holding the power button for a couple of seconds), and then power it on again. The kernel built by fedpkg showed the LUKS prompt on the first boot, but on the following 2 attempts, the screen stayed black. After that, I booted using the kernel built from the jwboyer tree. It showed the LUKS prompt 3 times in a row. After that, I tried the fedpkg kernel again, this time successful. So it seems like with the fedpkg kernel the LUKS prompt shows up only if the previous boot was not with that same kernel. But most importantly: if I build from jwboyer tree, it works all the time. So either something is wrong with debug symbol stripping and packaging, or I missed to install any essential rpm. How should I proceed? Here is the list of commands: fedpkg clone -a kernel cd kernel/ git checkout -b bisect 9457eae4a046ca1f467b5ccc95ca10868de51224 vim kernel.spec (%define buildid .local) fedpkg --release f26 prep // compare to jwboyer tree fedpkg --release f26 local cd x86_64 sudo dnf install kernel-4.14.4-200.local.fc26.x86_64.rpm kernel-core-4.14.4-200.local.fc26.x86_64.rpm kernel-modules-4.14.4-200.local.fc26.x86_64.rpm kernel-modules-extra-4.14.4-200.local.fc26.x86_64.rpm cd ../.. git clone git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git cd fedora/ git checkout -b bisect kernel-4.14.4-200.fc26 vim Makefile (set EXTRAVERSION) cp ../kernel/kernel-4.14.fc26/linux-4.14.4-200.local.fc26.x86_64/.config . make bzImage make modules sudo make modules_install sudo make install
As recent experiments point towards packaging, I rebuild the currently installed kernel (4.15.17-200.fc26) from jwboyer tree, using the config that got installed into /boot/. This kernel never hangs on boot. So it really looks like a packaging issue. How could I debug that? I guess I could try to perform part of the steps done for packaging manually and try to find which one introduces this bug. But the kernel.spec looks really complicated, so I welcome any hints on what to try.
The configs for the exploded tree are also included. Do you see any differences in linux-4.14.4-200.local.fc26.x86_64 and https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/tree/fedora/configs/kernel-4.14.4-x86_64.config?h=kernel-4.14.4-200.fc26&id=30760ce6098b431e1424e3f5c28084415c750749 ? I'm wondering if your local builds are picking up config differences that somehow make the behavior different. Aside from that, can you compare the contents of the initramfs for both the RPM and local builds? lsinitrd on both should show you the contents.
I'm experiencing the same issue and the same setup as described in comment 1. I've had this issue for some time F26, then F27, and as of yesterday F28. I had been able to stand on my foot, tap my head, all while reciting a magical incantation to get the laptop to boot while docked. An extremely annoying process, but I lived with it. The last kernel update for F27 seems to have broken the camel's back and nothing allowed it to boot while docked. Yesterday, after upgrading to F28 nothing seems to work. Cannot boot docked, and if booted while undocked, docking it locks it up.
Created attachment 1436276 [details] initramfs-4.14.4-200.local.fc26 contents, built by fedpkg
Created attachment 1436279 [details] initramfs-4.14.4 contents, built from jwboyer tree
Created attachment 1436280 [details] initramfs-4.15.17-200.fc26 contents, from official fedora repositories
Created attachment 1436281 [details] initramfs-4.15.17 contents, built from jwboyer tree
The diff between the configs you requested does not show anything relevant: --- kernel-4.14.4-x86_64.config?h=kernel-4.14.4-200.fc26 2018-05-14 17:29:24.000000000 +0200 +++ /boot/config-4.14.4-200.local.fc26.x86_64 2018-04-30 12:10:18.000000000 +0200 @@ -1,7 +1,6 @@ -# x86_64 # # Automatically generated file; DO NOT EDIT. -# Linux/x86_64 4.14.4 Kernel Configuration +# Linux/x86_64 4.14.4-200.local.fc26.x86_64 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y
Just a thought: it seems like we cannot pinpoint any code change. Could this be a compile time problem? Maybe some aggressive CFLAGS or security features? @Daniel: how did you compile the kernel from jwbouyer tree?
(In reply to Florian Engel from comment #33) > Just a thought: it seems like we cannot pinpoint any code change. Could this > be a compile time problem? Maybe some aggressive CFLAGS or security > features? @Daniel: how did you compile the kernel from jwbouyer tree? I am not explicitly setting any compile settings at all, despite setting the EXTRAVERSION in the Makefile. In comment #24 I listed all the commands I used for building that kernel, and I don't think I forgot anything. But I agree, it could also be related to optimization flags or the like.
I rebuilt 4.16.6 with jwboyer's repo and also see the LUKS prompt come up consistently. However, although it is a strange difference in behavior with the LUKS prompt, neither the fedora kernel nor the jwboyer one will boot with external monitors plugged in for me (this is post password entry). I'm pretty confident it's due to the nouveau driver and wonder if spending effort elsewhere would be more productive. That is of course unless jwboyer's kernel actually boots for others.
Folks, See -> https://bugzilla.redhat.com/show_bug.cgi?id=1573080#c13
I used the kernel 4.15.17 compiled from jwboyer tree for a whole day without any issues.
It works for me now! I've ugraded to F27 and with that came kernel 4.16.13-200.fc27. Using this kernel I can boot successfully while being docked. A coworker, who had been using F27 for some longer time, mentioned that the upgrade to kernel 4.16.12-200.fc27 fixed it for him. So I don't know if there are any other models that still suffer from this, but I personally consider this bug fixed. Thank you very much for your help and support.
I just updated my P50 running Fedora 28 to kernel-4.16.15-300.fc28.x86_64 and now I too can boot successfully while docked.
I'm booting with kernel-4.17.2-200.fc28.x86_64 while docked. It also worked with 4.16.16. It looks fixed!
Great, thanks for verifying.
This issue seems to be back with: kernel-4.17.2-200.fc28.x86_64 The lucks prompt doesn't come up when docked. Screenshot when it gets stuck is attached. Last good kernel version for me: kernel-4.16.15-300.fc28.x86_64 Re-opening.
Created attachment 1456132 [details] Screeenshot. Nothing more than this on boot with 4.17 when docked.
(In reply to Severin Gehwolf from comment #42) > Last good kernel version for me: > kernel-4.16.15-300.fc28.x86_64 Clarification: It seems to happen with --^ that kernel version too, but less frequently. Also: If I remove the laptop from the dock (when it's stuck) the boot process seems to continue and I get a non-graphical luks prompt.
kernel-4.17.3-200.fc28.x86_64 seems to be good again for me. Luks prompt appearing as expected.
(In reply to Severin Gehwolf from comment #45) > kernel-4.17.3-200.fc28.x86_64 seems to be good again for me. Luks prompt > appearing as expected. Scratch that. I'm still seeing this issue with that kernel too. It appears to reproduce more frequently when switching docking stations. In my case between work and home.
(In reply to Severin Gehwolf from comment #46) > (In reply to Severin Gehwolf from comment #45) > > kernel-4.17.3-200.fc28.x86_64 seems to be good again for me. Luks prompt > > appearing as expected. > > Scratch that. I'm still seeing this issue with that kernel too. It appears > to reproduce more frequently when switching docking stations. In my case > between work and home. I just booted 4.17.6-100.fc27 on this P50 while in its dock and it worked correcly.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
Changing to F28 as I've been seeing this issue on F28 for a while.
(In reply to Corey Ashford from comment #47) > I just booted 4.17.6-100.fc27 on this P50 while in its dock and it worked > correcly. Thanks for the info, Corey. FWIW, I've had the same experience with kernel-4.17.3-200.fc28.x86_64 initially. Then switched between work/home a couple of times and the issue resurfaced. It's a hit-and-miss problem for me. I've upgraded to 4.17.7-200 today and will use that for a while and report back.
With 4.17.7-100.fc27.x86_64 I am able to boot while docked, but after un-docking and re-docking my external display is not recognized.
(In reply to Robert Story from comment #51) > With 4.17.7-100.fc27.x86_64 I am able to boot while docked, but after > un-docking and re-docking my external display is not recognized. That could be bug 1477182. The combination of this bug and 1477182 (which I've had) is quite nasty.
(In reply to Severin Gehwolf from comment #50) > (In reply to Corey Ashford from comment #47) > > I just booted 4.17.6-100.fc27 on this P50 while in its dock and it worked > > correcly. > > Thanks for the info, Corey. FWIW, I've had the same experience with > kernel-4.17.3-200.fc28.x86_64 initially. Then switched between work/home a > couple of times and the issue resurfaced. It's a hit-and-miss problem for > me. I've upgraded to 4.17.7-200 today and will use that for a while and > report back. After having used 4.17.7-200 for a while now I'm seeing the same issue as with 4.17.3-200. It sometimes works, sometimes it doesn't.
(In reply to Severin Gehwolf from comment #53) > (In reply to Severin Gehwolf from comment #50) > > (In reply to Corey Ashford from comment #47) > > > I just booted 4.17.6-100.fc27 on this P50 while in its dock and it worked > > > correcly. > > > > Thanks for the info, Corey. FWIW, I've had the same experience with > > kernel-4.17.3-200.fc28.x86_64 initially. Then switched between work/home a > > couple of times and the issue resurfaced. It's a hit-and-miss problem for > > me. I've upgraded to 4.17.7-200 today and will use that for a while and > > report back. > > After having used 4.17.7-200 for a while now I'm seeing the same issue as > with 4.17.3-200. It sometimes works, sometimes it doesn't. I'm curious if you always dock while the P50 is suspended or while it's fully powered up? I always dock/undock my P50 while it's suspended. So far I've gone a couple of weeks that way without problems. Overall, though, I've noticed that the Nouveau driver just isn't that reliable. I keep contemplating switching to the proprietary drivers from Nvidia, but somehow the bugs in Nouveau haven't quite reached that required level of annoyance, with a problem only about once a week that requires a reboot.
(In reply to Corey Ashford from comment #54) > I'm curious if you always dock while the P50 is suspended or while it's > fully powered up? I always dock/undock my P50 while it's suspended. So far > I've gone a couple of weeks that way without problems. I usually dock/undock when it's fully powered down. I.e. it's booted up when already in the dock. I usually shutdown the P50 and then undock to take it with me after the end of the day.
Seems to me this has been an issue that has plagued Linux (in general) for quite some time (dare I say years). If you do a search, you'll find it's not just Fedora that has this issue. You'll see that Ubuntu, as well as others also have these same complaints. And I don't mean to blame the operating system, this may just as well be hardware issues. So while I can appreciate the people who perform some form of magical incantation (me being one of them) in order to get these laptops to work properly with docking/undocking,...that shouldn't mean we just live with the problem, and hope some future laptop, kernel update, or video driver solves this issue. BTW, this issue doesn't only affect Lenovo laptops (in this case the P50s). Again, if you do a search, you find plenty of others.
(In reply to John Prause from comment #56) > Seems to me this has been an issue that has plagued Linux (in general) for > quite some time (dare I say years). If you do a search, you'll find it's not > just Fedora that has this issue. You'll see that Ubuntu, as well as others > also have these same complaints. And I don't mean to blame the operating > system, this may just as well be hardware issues. > > So while I can appreciate the people who perform some form of magical > incantation (me being one of them) in order to get these laptops to work > properly with docking/undocking,...that shouldn't mean we just live with the > problem, and hope some future laptop, kernel update, or video driver solves > this issue. > > BTW, this issue doesn't only affect Lenovo laptops (in this case the P50s). > Again, if you do a search, you find plenty of others. Docking/undocking, suspend/resume are huge and chronic problems across Linux, and even Windows. One problem I have failed to report on Fedora (still FC27 at the moment but running the latest kernel), and have just lived with, is that suspend is very flakey. Usually the first couple of times I suspend my laptop, it wakes up again on its own within a few seconds. Sometimes I've had to suspend it four times before it will actually go all the way to "sleep", where the power LED on the laptop is just slowly fading in and out. My understanding is that the problems are simply very complex to understand and then to solve, involving many interconnected pieces of software and hardware. And they are never really "show-stoppers" so they don't get much attention.
Seeing this issue on F28 with KDE plasma using SDDM. Kernel upgrades haven't made a difference and I can anecdotally confirm the intermittency of boot success noted by Severin above. I am using proprietary nvidia drivers, how I wish I could just disable Nvidia completely in this laptop. If I SSH into the system from elsewhere and restart SDDM I usually have success, but only if the system has been booted for a minute or two in the 'hung' black screen state. Equally switching to a different TTY and restarting the SDDM achieves the same effect. Kernel - 4.18.10-200
I'm using F28/KDE/SDDM and I haven't had this issue for a while. Currently I'm on 4.18.16-200.fc28.x86_64. Booting and docking/undocking work well. I am using nouveau drivers.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
(In reply to Justin M. Forbes from comment #60) > Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel > update (or newer) and let us know if you issue has been resolved or if it is > still present with the newer kernel. Seems to work for me for a while now.
Thanks for the update