Created attachment 1686167 [details] journalctl --no-hostname -k -b -1 1. Please describe the problem: Happens since kernel update in Fedora 31 (5.6 and up) and now on Fedora 32 (kernel 5.6.8-300). I think all was fine on Fedora 31 kernel 5.5 (but I don't remember the exact version). Laptop (ThinkPad X1 Carbon 6th Gen) boots correctly when not connected to the docking station (40AJ, Ultra Docking Station). When laptop is connected to the docking station (mouse, keyboard, USB3 external disk, display port and VGA monitors), the boot sequence just stops after the Lenovo splash screen (the one just after the kernel/OS selection in GRUB2). What happens is that the display port monitor just go to sleep, and nothing else happens. When laptop lid is open, the boot sequence freezes at the splash screen (laptop screen stays on, but nothing happens). In order to make the laptop boot when on the docking station, I need to leave the laptop lid open, manually select the default kernel, and hit the arrow keys (from the laptop's keyboard) multiple times until I see the boot sequence. This doesn't work with the USB keyboard (connected via the docking station). 2. What is the Version-Release number of the kernel: 5.6.8-300.fc32.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : I think it first appeared at version 5.5 (Fedora 31). 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Connect the laptop to the docking station, leave the lid close (or open, for that matter), boot the laptop and leave it be. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: This happens for each three kernels installed (5.6.7-200.fc31.x86_64, 5.6.8-200.fc31.x86_64 and 5.6.8-300.fc32.x86_64). I did not try the latest Rawhide kernel. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Attached is the log from the following command after an unsuccessful boot. $ journalctl --no-hostname -k -b -1 > /tmp/dmesg-1.txt Please note that this log doesn't represent the actual boot sequence which failed (since it doesn't register in the kernel message log (i.e. I booted the laptop at 8AM (GMT-4) on the 7th of May, waited a bit while it was frozen, hard reset, boot using the quick fix mentioned and then run the command. The boot -1 shows entries for the 6th of May (AM).
This sounds like a problem which I have been seeing too with a X1C7, but which I have not been able to fully debug yet. 2 questions: 1. What happens if you turn the machine on with the lid closed (while docked) and leave the lid closed all the way ? For me it always boots reliably doing things this way. 2. What happens if you remove "rhgb" from the kernel commandline ?
(In reply to Hans de Goede from comment #1) > This sounds like a problem which I have been seeing too with a X1C7, but > which I have not been able to fully debug yet. > > 2 questions: > > 1. What happens if you turn the machine on with the lid closed (while > docked) and leave the lid closed all the way ? > For me it always boots reliably doing things this way. That's how I used to boot the machine (lid closed all the way). > > 2. What happens if you remove "rhgb" from the kernel commandline ? Same thing. I see the following lines: [ OK ] Started Show Plymouth Boot Screen. ... [ OK ] Reached target Basic System. Then, the displayport screen goes to sleep and nothing happens after. Here is what I just figured out. When I rebooted to boot without "rhgb", the displayport monitor stayed off (sometimes, this happens) but the VGA was on. There was a bunch of messages on the VGA monitor, and it froze (I didn't take a picture, since I thought this would happen again). If it does happen again, I'll take a picture. So I tried booting with the displayport monitor unplugged from the docking station, and the system booted normally (without and with "rhgb" flag, lid closed).
(In reply to Louis-P L Perreault from comment #2) > So I tried booting with the displayport monitor unplugged from the docking > station, and the system booted normally (without and with "rhgb" flag, lid > closed). And what happens if you boot with only the DisplayPort monitor (and not the VGA monitor) connected ? I have the feeling ths might be an issue which happens when you have more then 1 monitor connected on the dock. Also can you try the latest 5.7-rc# kernel, we might get lucky and this might already be fixed there, you can find that kernel here: https://koji.fedoraproject.org/koji/buildinfo?buildID=1503100 And here are some generic instructions for installing a kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt Since this is not a test/scratch build you do not have to disable secureboot to try this kernel.
(In reply to Hans de Goede from comment #3) > And what happens if you boot with only the DisplayPort monitor (and not the > VGA monitor) connected ? I have the feeling ths might be an issue which > happens when you have more then 1 monitor connected on the dock. You're right, the laptop boots as normal when only the displayport monitor is connected. I'll try the latest kernel later tonight. Since I've never installed a kernel that way, will I be able to easily revert back to the "official" kernels just by removing release candidate one?
(In reply to Louis-P L Perreault from comment #4) > Since I've never installed a kernel that way, will I be able to easily > revert back to the "official" kernels just by removing release candidate one? Yes if you remove the RC kernel with say dnf remove then grub will automatically boot the newest kernel from the set of still installed kernels.
(In reply to Hans de Goede from comment #3) > Also can you try the latest 5.7-rc# kernel, we might get lucky and this > might already be fixed there, you can find that kernel here: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1503100 I have the same issue with kernel 5.7.0-0.rc4.1.fc33.x86_64. It boots only when one monitor is plugged in (either DisplayPort or VGA), but not both at the same time.
(In reply to Louis-P L Perreault from comment #6) > (In reply to Hans de Goede from comment #3) > > Also can you try the latest 5.7-rc# kernel, we might get lucky and this > > might already be fixed there, you can find that kernel here: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1503100 > > I have the same issue with kernel 5.7.0-0.rc4.1.fc33.x86_64. It boots only > when one monitor is plugged in (either DisplayPort or VGA), but not both at > the same time. Ok thank you for trying. I've asked a colleague who knows more about this part of the kernel then me to take a look at this bug. I'm not sure when she will have time to look at this, but hopefully we will hear back from her soon(ish).
Hi! Like Hans said I am a bit busy right now, but thinkpads are somewhat high priority for me to keep working so I'll do my best to figure out what's going on here ASAP. First there's a couple of things I need from you: - Make sure you've got your laptop's firmware updated with fwupdmgr (this probably isn't the problem, but it's always worth making sure) - Boot your laptop with `drm.debug=0x116 log_buf_len=50M` added to the kernel boot parameters, reproduce hang, and then get the dmesg logs afterwards Note for grabbing dmesg logs it needs to be done during the same boot that the problem happens on, since otherwise I won't be able to see what the hub and laptop are doing. I'd think just unplugging the hub once your machine has frozen should be good enough to get it back into working order so you can grab the logs, but if your machine isn't recovering I'd recommend using netconsole or a serial console to get these logs: https://www.kernel.org/doc/Documentation/networking/netconsole.txt (if you're confused by this document let me know, I probably can give you one of my scripts for doing this) Also, it'd be useful to know what kind of displays you have hooked up, if they're HDMI/DisplayPort, what resolutions they're running at, if they support mst or are hooked up through another mst hub, etc. etc.
(In reply to Lyude from comment #8) > - Make sure you've got your laptop's firmware updated with fwupdmgr (this > probably isn't the problem, but it's always worth making sure) According to fwupdmgr, there are no updates available. > - Boot your laptop with `drm.debug=0x116 log_buf_len=50M` added to the > kernel boot parameters, reproduce hang, and then get the dmesg logs > afterwards I couldn't simply grab dmesg using journalctl, as once the laptop hangs, it cannot recover. I didn't have a lot of success with netconsole; it looks like the system hangs before netconsole can log anything on the network (the ethernet cable is connected through the dock). I tried rebooting the system multiple times, and I manage to get only one log out of this (dmesg_log.txt), though I don't know if it's relevant... > Also, it'd be useful to know what kind of displays you have hooked up, if > they're HDMI/DisplayPort, what resolutions they're running at, if they > support mst or are hooked up through another mst hub, etc. etc. The system hangs when there are two monitors plugged in: 1) Dell P2319H using DisplayPort, 1920x1080, 60Hz and 2) an old Dell E176FP using VGA, 1280x1024, 60Hz). They are hooked up directly on the docking station (which is in turn plugged to the laptop using two thunderbolt ports). I honestly don't know if there is any multi-stream involved... The docking station is a ThinkPad Ultra Docking Station (40AJ, https://support.lenovo.com/us/en/solutions/pd029622#Ultra%20Docking) with the ThinkPad X1 Carbon (6th gen). Thank you for your help!
Created attachment 1687832 [details] dmesg via netconsole
Could this be related to the Thunderbolt issue here? https://pcsupport.lenovo.com/sk/en/solutions/ht508988
The Thunderbolt firmware is at version 43. Also, the bug still happens with the latest kernel (5.6.16-300.fc32.x86_64) and two monitors plugged in. When I hard reset the machine (and unplugged the VGA monitor), the DisplayPort monitor did not wake. I had this ABRT report (https://retrace.fedoraproject.org/faf/reports/2942873/). If needed, I could report the issue to Bugzilla.
I have escaped crunch time and now my soul is free to help those in need of MST troubleshooting Anyway-it is extremely useful that you know how to use netconsole, could you get us another dmesg from netconsole after trying to plug in the dock with the following parameters added to your kernel commandline? drm.debug=0x116 log_buf_len=50M
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days