Description of problem: My Laptop(Lenovo T470s) freezes, when trying to mount on the Thinkpad ultradock. The dock is connected to 2 external monitors, Forcefully need to restart to get it working. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. power on laptop. 2. mount on to the docking station. 3. Laptop freezes. Actual results: Expected results: Additional info:
I've als been having intermittent freezing recently (as in, within the past couple of weeks) when placing my Lenovo T560 onto its dock. The only external hardware connected to the dock in my case is the standard audio connection (i.e., not USB audio). I have experienced 3 such freezes so far; the first scrambled the screen, and the other two just locked the system up to the point where it would not even respond to the key sequence to go to a virtual terminal. I have not yet tried logging in remotely during the frozen condition. Symptoms include the frozen screen, backlight stays on despite settings intended to blank the screen, and the CPU fan begins running, suggesting a high load from something. After reboot, I notice Evolution has to access newly received email, suggesting it was not able to run during the frozen condition. Right now, my experience suggests that this is an intermittent problem for me, rather than the 100% reproducible one of the original submitter, and it's only recently begun occurring for me. Kernel version is 4.19.8-200.fc28.x86_64, xorg version is 1.19.6-10.fc28.x86_64, and I'm using the Cinnamon environment. I have recently applied firmware updates, but the first freeze occurred prior to that update. Given that I tend to leave my laptop running for extended periods of time, it's possible that it could have been introduced sometime in September, with me only rebooting to the buggy software version(s) recently. The only unusual log I see in Xorg.0.log.old is this one: [ 8530.535] (II) event5 - TPPS/2 IBM TrackPoint: Enabling spurious button debouncing, see https://wayland.freedesktop.org/libinput/doc/1.11.3/button_debouncing.html for details This message does not appear in my current Xorg.0.log. My /var/log/messages looks normal up until about 19:45:16 local time, at which point there's a block of NUL characters before logging the kernel command line at the start of the reboot, at 23:07:58, when I noticed the laptop was wedged (I had put it on the dock to recharge after I finished with another task).
Just had this happen in Fedora 29. A look at Xorg.0.log.old reveals this: [115074.457] (EE) event4 - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.12.5/touchpad-jumping-cursors.html for details [159964.574] (EE) client bug: timer event5 debounce: offset negative (-6ms) [193673.608] (EE) event4 - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.12.5/touchpad-jumping-cursors.html for details [801177.071] (II) event5 - TPPS/2 IBM TrackPoint: Enabling spurious button debouncing, see https://wayland.freedesktop.org/libinput/doc/1.12.5/button-debouncing.html for details [1217147.238] (EE) client bug: timer event5 debounce short: offset negative (-2ms) [1238856.763] (II) event4 - SynPS/2 Synaptics TouchPad: SYN_DROPPED event - some input events have been lost. [1291153.720] (EE) event4 - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.12.5/touchpad-jumping-cursors.html for details [1386665.365] (EE) event4 - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and discarded. See https://wayland.freedesktop.org/libinput/doc/1.12.5/touchpad-jumping-cursors.html for details The timestamps suggest that these aren't really necessarily related, however. The /var/log/messages shows the same behavior as before: normal logs up to 22:15:29, then a block of nul characters, then messages related to the subsequent bootup at 22:17:04. I also ran journalctl and looked for the timestamp, but, as you might expect, didn't get any additional insights; right after the same message at 22:15:29, there's just "-- Reboot --" followed by boot-up messages. Symptomology was that the moment my laptop started to become electrically connected to the docking station, the screen went haywire; it was mostly static, but there were pixels in various places that were flashing. I attempted to ping the laptop from another machine, but it had clearly dropped off the network (at the very least). The intermittent nature of this bug persists; I've had the laptop in and out of its dock over and over again for quite some time, and even have suspended and unsuspended it on and off the dock without any untoward behavior. If ya'll can suggest some additional places to look for log messages, or additional debugging options to turn on, I'm more than happy to look; I'm rather unnerved by my laptop just randomly deciding to lock up when put back on its dock.
This is continuing to happen. Please, tell me _somebody_ is looking at this bug report and it's not just going to time out because it supposedly only happens on Fedora 28 (it doesn't, it also happens on Fedora 29!) or that you're waiting for more information (please, please, PLEASE tell me what new information you need and how to get it!). I've had my laptop freeze twice in the past 24 hours due to this bug, and it's not acceptable that this bug report is just sitting here without any feedback…
(In reply to Kevin L. Mitchell from comment #3) > This is continuing to happen. Please, tell me _somebody_ is looking at this > bug report and it's not just going to time out because it supposedly only > happens on Fedora 28 (it doesn't, it also happens on Fedora 29!) or that > you're waiting for more information (please, please, PLEASE tell me what new > information you need and how to get it!). I've had my laptop freeze twice > in the past 24 hours due to this bug, and it's not acceptable that this bug > report is just sitting here without any feedback… As a temporary fix you could try changing from wayland to xorg, and see if it is still happening. At least for me it worked out.!
I don't use wayland and never have; I use the Cinnamon desktop running on xorg.
Its only happening on Gnome on Wayland. I tried Gnome on Xorg and KDE/Deepin on both Wayland and Xorg, it is working fine. So, I dont think this is Wayland issue in particular.
Reassigning to rawhide as its still happening on rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
I don't know if this is related, but I've got a similar bug 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 GRUB). What happens is that the screens just go to sleep, and nothing else happens. In order to make the laptop boot, I need to leave the lid open, manually select the default kernel, and hit the arrow keys multiple times until I see the boot sequence. Should this be a different bug report?
(In reply to Louis-P L Perreault from comment #9) ... > Should this be a different bug report? Please open a new bug report and attach a log for the previous boot after rebooting from the hang: $ journalctl --no-hostname -k -b -1 > /tmp/dmesg-1.txt The "-b -1" option selects the log for the previous boot. You can just copy and paste what you wrote above into the new bug report.
(In reply to Steve from comment #10) > (In reply to Louis-P L Perreault from comment #9) > ... > > Should this be a different bug report? > > Please open a new bug report ... And please select "kernel" as the component.
(In reply to Steve from comment #10) > (In reply to Louis-P L Perreault from comment #9) > ... > > Should this be a different bug report? > > Please open a new bug report and attach a log for the previous boot after > rebooting from the hang: > > $ journalctl --no-hostname -k -b -1 > /tmp/dmesg-1.txt > > The "-b -1" option selects the log for the previous boot. > > You can just copy and paste what you wrote above into the new bug report. New bug report opened (see bug 1832907).
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. 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 '31'. 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 31 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 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.