Bug 1470960
Summary: | when docking: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Hutař <jhutar> | ||||||||
Component: | xorg-x11-server | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 29 | CC: | alexander.karlstad, arndt, avicenzi, bward, cdonnell, contact, dominik.schrempf, hogklint, jpaulovi, konrad.paumann, ofourdan, rob.hicks.wm, tigert, ttomecek, xgl-maint | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2019-11-27 21:45:24 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Jan Hutař
2017-07-14 07:00:59 UTC
Created attachment 1298137 [details]
`journalctl -f` during dock & freeze & resume
I am experiencing it too on Fedora 26 on a Lenovo Thinkpad T470p. kernel-4.12.12-300.fc26 xorg-x11-server-1.19.3-4.fc26 # lspci -k | grep -A 2 VGA 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04) Subsystem: Lenovo Device 505e Kernel driver in use: i915 This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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. I did experience it again with Fedora 28: # uname -a Linux rise.kp 4.16.6-302.fc28.x86_64 #1 SMP Wed May 2 00:07:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # lspci -k | grep -A 2 VGA 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04) Subsystem: Lenovo Device 505e Kernel driver in use: i915 Created attachment 1433024 [details]
journalctl during suspend/resume
As a side note: this bug seemed fixed for a few months and is happening again since a couple of days Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 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. For F28 and ThinkPad T470s it helped to update the BIOS to latest version (v1.25). After the BIOS update, the problem is gone. Just had this failure on my T430s, when attempting to dock with two monitors, running Fedora 28. [201651.344022] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201655.534180] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201656.916550] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201657.503509] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201658.875461] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201660.253380] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201660.949407] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [201661.295811] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to get link status $ uname -a Linux gauss 4.16.15-300.fc28.x86_64 #1 SMP Tue Jun 12 00:42:35 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ lspci -k | grep -A 2 VGA 00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07) Subsystem: Lenovo Device 2233 Kernel driver in use: i915 I also updated to latest Lenovo bios (1.34) last month hoping it would help this. Sorry for the string of comments. One last correction, I am running T460s. A further note, this has been happening to my particular machine since kernel 4.15.9-300.fc27.x86_64. I had found this somewhat workaround, not entirely confirmed, particular to Skylake processors: https://wiki.archlinux.org/index.php/intel_graphics#Skylake_support Essentially, create this file: /usr/share/X11/xorg.conf.d/20-intel.conf: Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection And since doing so, I seemed not to have had problems. Just looking back after my latest fedora update, I've noticed this file is missing (not sure which update removed it, but probably f37->f38). So I'm adding it back and will see if I reproduce this error again. Seems similar to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1552040 I also have this problem on my Lenovo ThinkPad X270 (20HN0012FR) (F27) (BIOS Revision: 1.31) The issue occurs while running a kernel > 4.15.17-300.fc27.x86_64 I tried two versions of "/usr/share/X11/xorg.conf.d/20-intel.conf" 1- (yours) Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection 2- (the one present in the link you posted https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1552040) Section "Device" Identifier "Intel Graphics" Driver "intel" Option "DRI" "3" EndSection Both of them do not seem to change anything. For the moment, every kernel > 4.15.17 I run on my computer sees the problem occuring when I wake the computer docked/Dock it for the second time when on. Also happens to me with Thinkpad Yoga X3 with Lenovo Thunderbolt 3 Dock, 4.17.3-200.fc28.x86_64, with 2 external monitors. First hotplug/unplug following a reboot everything works. Second hotplug the hang occurs and either a reboot or unplug (associated with wayland crashing) brings the machine back. Note: this happens even without a suspend/hibernate cycle. Some dmesg output: [Mon Jul 9 16:59:49 2018] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [Mon Jul 9 16:59:49 2018] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns [Mon Jul 9 16:59:49 2018] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [Mon Jul 9 16:59:49 2018] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns [Mon Jul 9 16:59:49 2018] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [Mon Jul 9 16:59:49 2018] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns [Mon Jul 9 16:59:49 2018] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [Mon Jul 9 16:59:50 2018] [drm:intel_dp_start_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns Created attachment 1457771 [details]
journalctl -f
has journalctl entries just before unplugging dock ("Unplug Dock") and plugging back in ("Plug Dock")
Also on most recent bios for X1 Yoga 3 available right now (1.21). Since the bios upgrade this morning, the problem appears every time the dock is unplugged and plugged back in (including the first time after a reboot). I just had this problem pop up again yesterday and this morning. This time I have a completely rebuilt F28 system (other problem required a rebuild). I added the same xorg script. Actually I'm wondering if the xorg script `/usr/share/X11/xorg.conf.d/20-intel.conf` is even used with the default Wayland. In the last four weeks, since the system build on June 19, I had not seen this problem. I'm happy to work with a knowledgeable display-dev if anyone is willing to help debug this. I can potentially find another machine (or two?) to do some hard testing. So it seems that the root of the problem starts when undocking the laptop. dmesg reports: [ 129.883985] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [ 130.152462] [drm:intel_encoders_pre_enable.isra.96 [i915]] *ERROR* failed to allocate vcpi After re-docking, the aforementioned messages appear: [Mon Jul 9 16:59:49 2018] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit as a result. This happens regardless of whether there is /usr/share/X11/xorg.conf.d/20-intel.conf present or not. Oh, and obviously, I run Xorg, not Wayland. Jakub, Thanks for pointing that out. I can confirm this. [113886.057399] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [113886.326015] [drm:intel_encoders_pre_enable.isra.96 [i915]] *ERROR* failed to allocate vcpi [113892.941355] [drm:intel_power_domains_verify_state [i915]] *ERROR* power well DDI C IO power well state mismatch (refcount 1/enabled 0) [116758.735092] [drm:intel_power_domains_verify_state [i915]] *ERROR* power well DDI C IO power well state mismatch (refcount 1/enabled 0) [116773.545780] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit [116774.732033] [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit I have tried both xorg and wayland and reproduce this on both. Seems to be more an issue in the kernel driver than either wayland or xorg, right? Or maybe the dock firmware? Also, I found that this happens when I undock from my office dock more frequently than my home dock. I'd need to test it out more to really confirm that. But this week I know I've undocked from my home dock an redocked at office and things worked fine. Of course, that could just be a result of what order I do things relative to a fresh boot. Just another small update: Happens with the latest dock firmware 2.33.000, happens with any kind of setup of 2 monitors (DP + DVI, DP + VGA, HDMI + DVI/VGA), if only one monitor is connected (regardless of connection type) everything works fine. I also have uptodate firmware for my T470p and dock. And I also have 2 monitors connected to the dock. journalctl output after undocking: kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training kernel: [drm:intel_encoders_pre_enable.isra.96 [i915]] *ERROR* failed to allocate vcpi journalctl after sleep -> resume -> docking: kernel: [drm:intel_power_domains_verify_state [i915]] *ERROR* power well DDI D IO power well state mismatch (refcount 2/enabled 0) kernel: [drm:intel_display_resume [i915]] *ERROR* Restoring old state failed with -22 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF D idle bit kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF D idle bit kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF D idle bit kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF D idle bit I noticed an update was available for my ThinkPad X270 (specs. above). BIOS Revision: 1.32 Installing this BIOS did not to change anything either, as soon as I booted to a kernel released after 4.15.17-300 the problem happened again. I can also reproduce on my Fedora 28 on Lenovo T470s. To reproduce I just need to dock my laptop and unlock the screen. out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): EDID vendor "DEL", prod id 41179 out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Using hsync ranges from config file out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Using vrefresh ranges from config file out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Printing DDC gathered Modelines: out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz eP) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1600x900"x60.0 119.00 1600 1696 1864 2128 900 901 904 932 -hsync +vsync (55.9 kHz e) out 04 12:17:42 /usr/libexec/gdm-x-session[2368]: (II) modeset(0): Modeline "1920x1080"x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) out 04 12:17:42 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit out 04 12:17:42 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit out 04 12:17:42 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit out 04 12:17:42 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit out 04 12:17:42 kernel: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit I experience the exact same behavior and log output on my Dell Precision 5520 when undocking and redocking with thunderbolt. Although this is on Arch... kernel 4.18.12. My colleague has the same problem with Ubuntu 18.04 on the same laptop model. Feel free to remove my comment if it's irrelevant due to it being in regards to other distros. Same issue for me: I am running up to date F29, have up to date bios. Thinkpad T480s I also have uptodate firmware for my T470p and dock. And I also have 2 monitors connected to the dock. It did resolve for a few weeks. But yesterday I updated to F29 and to a new BIOSD for the T470p and now this bug is back again. I cannot say if it is because of the BIOS update or the Fedora major version upgrade. I have T460s, and this happens for me too - when two external monitors are connected via the dock. I get a lot of these when I plug in the dock with two Displayport monitors connected: [drm:intel_ddi_prepare_link_retrain [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit And this when I unplug: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to get link status It recovers itself shortly after when I unplug. This is Fedora 29, upgraded through a bunch of releases though, thus setting version bump so this does not get closed. Just wanted to confirm this on Lenovo X270. Linux schwarzbaer 4.19.4-arch1-1-ARCH #1 SMP PREEMPT Fri Nov 23 09:06:58 UTC 2018 x86_64 GNU/Linux Error happens after dock - undock sequence. [16602.267927] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training [16602.536220] [drm:intel_encoders_pre_enable.isra.65 [i915]] *ERROR* failed to allocate vcpi [16602.904892] ------------[ cut here ]------------ [16602.904893] vblank wait timed out on crtc 1 [16602.904930] WARNING: CPU: 2 PID: 2066 at drivers/gpu/drm/drm_vblank.c:1084 drm_wait_one_vblank+0x15c/0x170 [drm] [16602.904931] Modules linked in: ccm fuse snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic joydev snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc i915 iptable_security snd_soc_sst_dsp intel_rapl iptable_raw snd_hda_ext_core iptable_mangle snd_soc_acpi_intel_match snd_soc_acpi iptable_nat nf_nat_ipv4 arc4 x86_pkg_temp_thermal nf_nat intel_powerclamp iTCO_wdt iTCO_vendor_support coretemp snd_soc_core ipt_REJECT nf_reject_ipv4 xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c kvmgt vfio_mdev iptable_filter mdev snd_compress ac97_bus vfio_iommu_type1 snd_pcm_dmaengine vfio snd_hda_intel iwlmvm snd_hda_codec wmi_bmof intel_wmi_thunderbolt e1000e kvm mac80211 i2c_algo_bit drm_kms_helper snd_hda_core irqbypass iwlwifi intel_cstate intel_uncore snd_hwdep uvcvideo intel_rapl_perf [16602.904962] nls_iso8859_1 nls_cp437 drm pcspkr vfat fat snd_pcm psmouse btusb btrtl cfg80211 btbcm btintel videobuf2_vmalloc videobuf2_memops mousedev bluetooth videobuf2_v4l2 videobuf2_common i2c_i801 snd_timer intel_gtt uas videodev mei_me thinkpad_acpi tpm_crb input_leds agpgart nvram snd rtsx_pci_ms media ecdh_generic memstick syscopyarea mei tps6598x sysfillrect idma64 sysimgblt fb_sys_fops intel_lpss_pci rfkill intel_lpss intel_pch_thermal tpm_tis typec wmi tpm_tis_core soundcore battery ac tpm evdev mac_hid rng_core pcc_cpufreq auth_rpcgss sunrpc ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto algif_skcipher af_alg sd_mod hid_generic usbhid hid usb_storage scsi_mod dm_crypt dm_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc rtsx_pci_sdmmc serio_raw [16602.905007] mmc_core atkbd libps2 aesni_intel aes_x86_64 xhci_pci crypto_simd cryptd glue_helper xhci_hcd rtsx_pci i8042 serio [16602.905016] CPU: 2 PID: 2066 Comm: Xorg Not tainted 4.19.4-arch1-1-ARCH #1 [16602.905017] Hardware name: LENOVO 20HN0014HV/20HN0014HV, BIOS R0IET52W (1.30 ) 03/20/2018 [16602.905027] RIP: 0010:drm_wait_one_vblank+0x15c/0x170 [drm] [16602.905029] Code: ed 0f 0b e9 32 ff ff ff 48 89 e6 4c 89 f7 e8 0b 6f 6e ed 45 85 e4 0f 85 14 ff ff ff 89 ee 48 c7 c7 a8 8d c0 c0 e8 6e e2 69 ed <0f> 0b e9 ff fe ff ff e8 58 df 69 ed 0f 1f 84 00 00 00 00 00 0f 1f [16602.905030] RSP: 0018:ffffaab9025d7ac0 EFLAGS: 00010282 [16602.905031] RAX: 0000000000000000 RBX: ffffa27012c20000 RCX: 0000000000000000 [16602.905032] RDX: 0000000000000007 RSI: ffffffffaf29e3ce RDI: 00000000ffffffff [16602.905033] RBP: 0000000000000001 R08: 0000000000000001 R09: 00000000000004dd [16602.905034] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 [16602.905035] R13: 000000000001e4ac R14: ffffa27016612978 R15: ffffa2701dd2f800 [16602.905036] FS: 00007f42772bfdc0(0000) GS:ffffa27022500000(0000) knlGS:0000000000000000 [16602.905037] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [16602.905038] CR2: 0000000002247808 CR3: 00000003bce20004 CR4: 00000000003606e0 [16602.905039] Call Trace: [16602.905045] ? wait_woken+0x80/0x80 [16602.905076] skl_update_crtcs+0x1cc/0x2c0 [i915] [16602.905102] intel_atomic_commit_tail+0x347/0xd20 [i915] [16602.905127] intel_atomic_commit+0x2ad/0x2e0 [i915] [16602.905140] drm_mode_atomic_ioctl+0x824/0x940 [drm] [16602.905153] ? drm_atomic_set_property+0x690/0x690 [drm] [16602.905161] drm_ioctl_kernel+0xa7/0xf0 [drm] [16602.905170] drm_ioctl+0x30e/0x3c0 [drm] [16602.905182] ? drm_atomic_set_property+0x690/0x690 [drm] [16602.905185] ? __switch_to_asm+0x40/0x70 [16602.905187] ? __switch_to_asm+0x34/0x70 [16602.905188] ? __switch_to_asm+0x40/0x70 [16602.905191] do_vfs_ioctl+0xa4/0x630 [16602.905193] ksys_ioctl+0x60/0x90 [16602.905195] __x64_sys_ioctl+0x16/0x20 [16602.905197] do_syscall_64+0x5b/0x170 [16602.905199] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [16602.905201] RIP: 0033:0x7f4279edb80b [16602.905203] Code: 0f 1e fa 48 8b 05 55 b6 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 25 b6 0c 00 f7 d8 64 89 01 48 [16602.905204] RSP: 002b:00007ffddb5f8c48 EFLAGS: 00003246 ORIG_RAX: 0000000000000010 [16602.905205] RAX: ffffffffffffffda RBX: 000056080c79fb10 RCX: 00007f4279edb80b [16602.905206] RDX: 00007ffddb5f8c90 RSI: 00000000c03864bc RDI: 000000000000000e [16602.905207] RBP: 00007ffddb5f8c90 R08: 000056080c8c9c60 R09: 0000000000000001 [16602.905208] R10: 0000000000000001 R11: 0000000000003246 R12: 00000000c03864bc [16602.905209] R13: 000000000000000e R14: 0000000000000000 R15: 000056080cc5e840 [16602.905211] ---[ end trace dca28345689a085e ]--- [16603.153764] audit: type=1130 audit(1543407758.195:116): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [16612.942557] audit: type=1131 audit(1543407767.985:117): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [16613.204917] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:55:pipe B] flip_done timed out [16623.871558] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:55:pipe B] flip_done timed out [16633.898149] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:109:DP-4] flip_done timed out [16643.924788] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:42:plane 1B] flip_done timed out I can reproduce on Lenovo T470s. Fedora 29 Kernel 4.19.3-300.fc29.x86_64 Hello everyone, This is a DRM kernel module issue. Please check out these related bugs on Freenode: https://bugs.freedesktop.org/show_bug.cgi?id=107546 https://bugs.freedesktop.org/show_bug.cgi?id=108616 https://bugs.freedesktop.org/show_bug.cgi?id=106250 And this one on Red Hat's bugzilla perhaps more appropriately filed under intel drivers component: https://bugzilla.redhat.com/show_bug.cgi?id=1598819 My issue was resolved with the latest 4.20 kernel. 4.20.3-200.fc29.x86_64 This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. 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 '29'. 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 29 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 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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. |