Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1527669 - Can't boot ThinkPad P50 docked
Summary: Can't boot ThinkPad P50 docked
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Eddie Kovsky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1528041 1535587 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-19 20:48 UTC by Jim Scarborough
Modified: 2019-01-29 19:25 UTC (History)
45 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-01-29 19:25:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
initramfs-4.14.4-200.local.fc26 contents, built by fedpkg (219.27 KB, text/plain)
2018-05-14 15:22 UTC, Daniel Böhme
no flags Details
initramfs-4.14.4 contents, built from jwboyer tree (216.73 KB, text/plain)
2018-05-14 15:23 UTC, Daniel Böhme
no flags Details
initramfs-4.15.17-200.fc26 contents, from official fedora repositories (218.12 KB, text/plain)
2018-05-14 15:24 UTC, Daniel Böhme
no flags Details
initramfs-4.15.17 contents, built from jwboyer tree (216.73 KB, text/plain)
2018-05-14 15:25 UTC, Daniel Böhme
no flags Details
Screeenshot. Nothing more than this on boot with 4.17 when docked. (1.70 MB, image/jpeg)
2018-07-03 07:26 UTC, Severin Gehwolf
no flags Details

Description Jim Scarborough 2017-12-19 20:48:08 UTC
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.

Comment 1 Laura Abbott 2017-12-20 21:35:02 UTC
*** Bug 1528041 has been marked as a duplicate of this bug. ***

Comment 2 Laura Abbott 2017-12-20 21:37:46 UTC
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.

Comment 3 Brent Baude 2017-12-20 22:15:43 UTC
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.

Comment 4 Jens Alpers 2018-01-08 15:48:01 UTC
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.

Comment 5 Václav Kadlčík 2018-01-09 06:40:37 UTC
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.

Comment 6 Pete Savage 2018-01-09 11:28:09 UTC
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.

Comment 7 Jon Levell 2018-01-09 11:46:12 UTC
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

Comment 8 Corey Ashford 2018-01-18 00:54:32 UTC
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.

Comment 9 Jeff Peeler 2018-01-26 21:40:16 UTC
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).

Comment 11 Jim Scarborough 2018-01-30 13:04:13 UTC
This may be the same as bug 1509294.

Comment 12 Florian Engel 2018-02-13 11:56:22 UTC
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).

Comment 13 Florian Engel 2018-02-20 13:11:27 UTC
I am still seeing this issue with 4.15.3.

Comment 14 Daniel Böhme 2018-02-26 17:22:50 UTC
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.

Comment 15 Jim Scarborough 2018-02-27 17:42:20 UTC
4.15.4-300.fc27.x86_64 fails to boot.

Comment 16 Laura Abbott 2018-02-27 18:21:45 UTC
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.

Comment 17 Michael Epley 2018-03-06 21:54:18 UTC
Also experiencing this issue, but have not attempted diagnostics.

Comment 18 Robert Story 2018-03-23 17:58:18 UTC
Still no luck with 4.15.10-300.fc27.x86_64.

Comment 19 Severin Gehwolf 2018-04-05 15:33:01 UTC
*** Bug 1535587 has been marked as a duplicate of this bug. ***

Comment 20 Daniel Böhme 2018-04-10 16:00:24 UTC
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.

Comment 21 Jeff Peeler 2018-04-11 20:41:58 UTC
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.

Comment 22 Brent Baude 2018-05-01 22:54:20 UTC
FWIW, this is probably now a blocker for us to migrate to f28

Comment 23 Florian Engel 2018-05-02 09:11:32 UTC
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.

Comment 24 Daniel Böhme 2018-05-02 10:16:25 UTC
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

Comment 25 Daniel Böhme 2018-05-04 07:24:17 UTC
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.

Comment 26 Josh Boyer 2018-05-04 15:21:29 UTC
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.

Comment 27 John Prause 2018-05-09 13:35:57 UTC
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.

Comment 28 Daniel Böhme 2018-05-14 15:22:39 UTC
Created attachment 1436276 [details]
initramfs-4.14.4-200.local.fc26 contents, built by fedpkg

Comment 29 Daniel Böhme 2018-05-14 15:23:49 UTC
Created attachment 1436279 [details]
initramfs-4.14.4 contents, built from jwboyer tree

Comment 30 Daniel Böhme 2018-05-14 15:24:52 UTC
Created attachment 1436280 [details]
initramfs-4.15.17-200.fc26 contents, from official fedora repositories

Comment 31 Daniel Böhme 2018-05-14 15:25:39 UTC
Created attachment 1436281 [details]
initramfs-4.15.17 contents, built from jwboyer tree

Comment 32 Daniel Böhme 2018-05-14 15:31:55 UTC
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

Comment 33 Florian Engel 2018-05-14 16:03:38 UTC
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?

Comment 34 Daniel Böhme 2018-05-17 16:52:01 UTC
(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.

Comment 35 Jeff Peeler 2018-05-17 17:23:43 UTC
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.

Comment 36 Brent Baude 2018-05-21 21:38:08 UTC
Folks,

See -> https://bugzilla.redhat.com/show_bug.cgi?id=1573080#c13

Comment 37 Daniel Böhme 2018-05-29 07:40:19 UTC
I used the kernel 4.15.17 compiled from jwboyer tree for a whole day without any issues.

Comment 38 Daniel Böhme 2018-06-18 13:36:33 UTC
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.

Comment 39 Mat Booth 2018-06-18 15:18:52 UTC
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.

Comment 40 Jim Scarborough 2018-06-26 20:31:23 UTC
I'm booting with kernel-4.17.2-200.fc28.x86_64 while docked. It also worked with 4.16.16.  It looks fixed!

Comment 41 Jeremy Cline 2018-06-27 13:24:06 UTC
Great, thanks for verifying.

Comment 42 Severin Gehwolf 2018-07-03 07:24:31 UTC
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.

Comment 43 Severin Gehwolf 2018-07-03 07:26:11 UTC
Created attachment 1456132 [details]
Screeenshot. Nothing more than this on boot with 4.17 when docked.

Comment 44 Severin Gehwolf 2018-07-06 08:38:01 UTC
(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.

Comment 45 Severin Gehwolf 2018-07-17 07:53:54 UTC
kernel-4.17.3-200.fc28.x86_64 seems to be good again for me. Luks prompt appearing as expected.

Comment 46 Severin Gehwolf 2018-07-20 08:09:09 UTC
(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.

Comment 47 Corey Ashford 2018-07-20 17:56:03 UTC
(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.

Comment 48 Justin M. Forbes 2018-07-23 14:55:17 UTC
*********** 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.

Comment 49 Severin Gehwolf 2018-07-23 15:06:29 UTC
Changing to F28 as I've been seeing this issue on F28 for a while.

Comment 50 Severin Gehwolf 2018-07-23 15:13:40 UTC
(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.

Comment 51 Robert Story 2018-07-24 20:50:38 UTC
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.

Comment 52 Severin Gehwolf 2018-07-25 07:24:49 UTC
(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.

Comment 53 Severin Gehwolf 2018-07-30 16:28:30 UTC
(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.

Comment 54 Corey Ashford 2018-07-30 17:35:21 UTC
(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.

Comment 55 Severin Gehwolf 2018-07-31 08:02:09 UTC
(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.

Comment 56 John Prause 2018-07-31 13:53:16 UTC
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.

Comment 57 Corey Ashford 2018-07-31 18:45:28 UTC
(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.

Comment 58 akretzsc 2018-10-02 23:38:12 UTC
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

Comment 59 Robert Story 2018-11-08 19:49:16 UTC
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.

Comment 60 Justin M. Forbes 2019-01-29 16:23:56 UTC
*********** 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.

Comment 61 Severin Gehwolf 2019-01-29 16:40:35 UTC
(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.

Comment 62 Justin M. Forbes 2019-01-29 19:25:16 UTC
Thanks for the update


Note You need to log in before you can comment on or make changes to this bug.