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-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 29CC: 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 Flags
`journalctl -f` during dock & freeze & resume
none
journalctl during suspend/resume
none
journalctl -f none

Description Jan Hutař 2017-07-14 07:00:59 UTC
Description of problem:
When I attempted to dock mine laptop I have resumed from sleep a while ago, I got mentioned error in the journal and despite mouse was moving, I could not click and keybord was stuck as well. It "fixed" after few seconds when I disconnected laptop from the docking station.


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.19.3-4.fc26.x86_64
kernel-4.11.9-300.fc26.x86_64
xfce4-session-4.12.1-10.fc26.x86_64

# lspci -k | grep -A 2 VGA 
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
	Subsystem: Lenovo Device 2210
	Kernel driver in use: i915


How reproducible:
rarely


Steps to Reproduce:
Very unclear, but I believe this could be it:
1. Dock & undock
2. Suspend & resume
3. Dock


Actual results:
Freeze until I undock, only mouse is moving


Expected results:
Should work

Comment 1 Jan Hutař 2017-07-14 07:05:04 UTC
Created attachment 1298137 [details]
`journalctl -f` during dock & freeze & resume

Comment 2 Konrad Paumann 2017-09-18 06:40:51 UTC
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

Comment 3 Fedora End Of Life 2018-05-03 08:41:07 UTC
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.

Comment 4 Konrad Paumann 2018-05-08 06:57:03 UTC
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

Comment 5 Konrad Paumann 2018-05-08 07:09:37 UTC
Created attachment 1433024 [details]
journalctl during suspend/resume

Comment 6 Konrad Paumann 2018-05-08 07:13:06 UTC
As a side note: this bug seemed fixed for a few months and is happening again since a couple of days

Comment 7 Fedora End Of Life 2018-05-29 12:56:39 UTC
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.

Comment 8 Jakub Samuel Paulovic 2018-05-31 11:28:16 UTC
For F28 and ThinkPad T470s it helped to update the BIOS to latest version (v1.25). After the BIOS update, the problem is gone.

Comment 9 Brian Ward 2018-06-18 13:28:55 UTC
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

Comment 10 Brian Ward 2018-06-18 13:30:59 UTC
I also updated to latest Lenovo bios (1.34) last month hoping it would help this.

Comment 11 Brian Ward 2018-06-18 13:31:54 UTC
Sorry for the string of comments.  One last correction, I am running T460s.

Comment 12 Brian Ward 2018-06-18 14:56:01 UTC
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

Comment 13 Maxime André 2018-07-04 06:28:52 UTC
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.

Comment 14 Rob Hicks 2018-07-09 15:17:40 UTC
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

Comment 15 Rob Hicks 2018-07-10 10:58:23 UTC
Created attachment 1457771 [details]
journalctl -f

has journalctl entries just before unplugging dock ("Unplug Dock") and plugging back in ("Plug Dock")

Comment 16 Rob Hicks 2018-07-10 11:03:29 UTC
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).

Comment 17 Brian Ward 2018-07-12 15:29:48 UTC
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.

Comment 18 Jakub Samuel Paulovic 2018-07-18 09:05:07 UTC
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.

Comment 19 Brian Ward 2018-07-20 15:55:19 UTC
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.

Comment 20 Jakub Samuel Paulovic 2018-08-02 09:50:44 UTC
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.

Comment 21 Konrad Paumann 2018-08-03 13:54:32 UTC
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

Comment 22 Maxime André 2018-09-26 13:19:13 UTC
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.

Comment 23 Alexandre Vicenzi 2018-10-04 10:36:41 UTC
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

Comment 24 Jimmie Högklint 2018-10-18 06:39:15 UTC
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.

Comment 25 Tomas Tomecek 2018-11-09 10:02:49 UTC
Same issue for me: I am running up to date F29, have up to date bios. Thinkpad T480s

Comment 26 Konrad Paumann 2018-11-20 15:08:22 UTC
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.

Comment 27 Tuomas Kuosmanen 2018-11-22 07:04:50 UTC
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.

Comment 28 dominik.schrempf 2018-11-28 12:38:52 UTC
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

Comment 29 Alexandre Vicenzi 2018-11-28 15:42:25 UTC
I can reproduce on Lenovo T470s.

Fedora 29
Kernel 4.19.3-300.fc29.x86_64

Comment 30 Brian Ward 2018-11-29 02:19:54 UTC
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

Comment 31 Brian Ward 2019-01-28 14:09:39 UTC
My issue was resolved with the latest 4.20 kernel.

4.20.3-200.fc29.x86_64

Comment 32 Ben Cotton 2019-10-31 19:41:41 UTC
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.

Comment 33 Ben Cotton 2019-11-27 21:45:24 UTC
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.