Bug 101825 - Skylake / driver fills logs with (EE) modeset(0): present flip failed loop
Summary: Skylake / driver fills logs with (EE) modeset(0): present flip failed loop
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/modesetting (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-17 21:11 UTC by Marc MERLIN
Modified: 2018-12-13 18:09 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
drm.debug=0x1e log_buf_len=1M (6.25 MB, text/plain)
2017-12-02 23:32 UTC, Konstantin
no flags Details

Description Marc MERLIN 2017-07-17 21:11:47 UTC
I have a thinkpad P70 with debian testing and 4.11.6 kernel.
A recent-ish upgrade broke something and now I'm getting loads of spam in my Xorg.log

[  5031.435] (WW) modeset(0): flip queue failed: Invalid argument
[  5031.435] (WW) modeset(0): Page flip failed: Invalid argument
[  5031.435] (EE) modeset(0): present flip failed
[  5031.519] (WW) modeset(0): flip queue failed: Invalid argument
[  5031.519] (WW) modeset(0): Page flip failed: Invalid argument
[  5031.519] (EE) modeset(0): present flip failed
(...)
by loads of spam I mean several hundred megabytes per day
The X server hangs every few days and when it works, 3D performance seems poor

system info:
ii  libdrm-intel1:amd64        2.4.74-1
ii  xserver-xorg-core          2:1.19.2-1
ii  xserver-xorg-video-intel   2:2.99.917+git20161206-1

Debian seems to require the use of the modsetting driver:
xserver-xorg-video-intel (2:2.13.0-2) unstable; urgency=low

  * Starting from 2.10, the Intel X driver depends on a kernel driver for
    mode setting (that's called KMS). The corresponding kernel option is
    CONFIG_DRM_I915, and is enabled in Debian kernels.
  * To enable KMS, either of those should be sufficient:
     + /etc/modprobe.d/i915-kms.conf should contain:
         options i915 modeset=1

kernel: 4.11.6-amd64-preempt

saruman:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7a cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 1 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:modesetting

[    73.575] (II) xfree86: Adding drm device (/dev/dri/card1)
[    73.576] (II) xfree86: Adding drm device (/dev/dri/card0)
[    73.588] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @ 0xd2000000/16777216, 0x60000000/536870912, I/O @ 0x00006000/64, BIOS @ 0x????????/131072
[    73.588] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @ 0xd3000000/16777216, 0xc0000000/268435456, 0xd0000000/33554432, I/O @ 0x00005000/128, BIOS @
????????/524288
[    73.597] (II) LoadModule: "modesetting"
[    73.597] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    73.598] (II) Module modesetting: vendor="X.Org Foundation"
[    73.598]    compiled for 1.19.2, module version = 1.19.2
[    73.598]    Module class: X.Org Video Driver
[    73.598]    ABI class: X.Org Video Driver, version 23.0
[    73.598] (II) LoadModule: "fbdev"
[    73.598] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[    73.598] (II) Module fbdev: vendor="X.Org Foundation"
[    73.598]    compiled for 1.19.0, module version = 0.4.4
[    73.598]    Module class: X.Org Video Driver
[    73.598]    ABI class: X.Org Video Driver, version 23.0
[    73.598] (II) LoadModule: "vesa"
[    73.598] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[    73.599] (II) Module vesa: vendor="X.Org Foundation"
[    73.599]    compiled for 1.19.0, module version = 2.3.4
[    73.599]    Module class: X.Org Video Driver
[    73.599]    ABI class: X.Org Video Driver, version 23.0
[    73.599] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[    73.599] (II) FBDEV: driver for framebuffer: fbdev
[    73.599] (II) VESA: driver for VESA chipsets: vesa
[    73.637] (II) modeset(0): using drv /dev/dri/card0
[    73.637] (II) modeset(G0): using drv /dev/dri/card1

In case it helps:
saruman:~#  grep . /sys/module/i915/parameters/*
/sys/module/i915/parameters/alpha_support:0
/sys/module/i915/parameters/disable_display:N
/sys/module/i915/parameters/disable_power_well:1
/sys/module/i915/parameters/edp_vswing:0
/sys/module/i915/parameters/enable_cmd_parser:Y
/sys/module/i915/parameters/enable_dc:-1
/sys/module/i915/parameters/enable_dpcd_backlight:N
/sys/module/i915/parameters/enable_dp_mst:Y
/sys/module/i915/parameters/enable_execlists:1
/sys/module/i915/parameters/enable_fbc:1
/sys/module/i915/parameters/enable_guc_loading:0
/sys/module/i915/parameters/enable_guc_submission:0
/sys/module/i915/parameters/enable_gvt:N
/sys/module/i915/parameters/enable_hangcheck:Y
/sys/module/i915/parameters/enable_ips:1
/sys/module/i915/parameters/enable_ppgtt:3
/sys/module/i915/parameters/enable_psr:0
/sys/module/i915/parameters/enable_rc6:1
/sys/module/i915/parameters/error_capture:Y
/sys/module/i915/parameters/fastboot:N
/sys/module/i915/parameters/force_reset_modeset_test:N
/sys/module/i915/parameters/guc_log_level:-1
/sys/module/i915/parameters/inject_load_failure:0
/sys/module/i915/parameters/invert_brightness:0
/sys/module/i915/parameters/load_detect_test:N
/sys/module/i915/parameters/lvds_channel_mode:0
/sys/module/i915/parameters/lvds_use_ssc:-1
/sys/module/i915/parameters/mmio_debug:0
/sys/module/i915/parameters/modeset:1
/sys/module/i915/parameters/nuclear_pageflip:N
/sys/module/i915/parameters/panel_ignore_lid:1
/sys/module/i915/parameters/prefault_disable:N
/sys/module/i915/parameters/reset:Y
/sys/module/i915/parameters/semaphores:0
/sys/module/i915/parameters/use_mmio_flip:0
/sys/module/i915/parameters/vbt_sdvo_panel_type:-1
/sys/module/i915/parameters/verbose_state_checks:Y
Comment 1 Ben Widawsky 2017-07-17 22:33:57 UTC
Can you identify which component was upgraded causing the breakage?

Would be good to add drm.debug=0x14 and see if we can figure out why EINVAL.
Comment 2 Marc MERLIN 2017-07-18 03:27:26 UTC
(In reply to Ben Widawsky from comment #1)
> Can you identify which component was upgraded causing the breakage?
> 
> Would be good to add drm.debug=0x14 and see if we can figure out why EINVAL.

I added 
options i915 modeset=1 drm.debug=0x14
to /etc/modprobe.d/i915-kms.conf
I'm not sure it made a difference though. Which log is it supposed to make a difference in? I see nothing special in dmesg:
[    3.410629] [drm] Replacing VGA console driver
[    3.416101] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    3.416107] [drm] Driver supports precise vblank timestamp query.
[    3.417439] random: fast init done
[    3.424422] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_26.bin (v1.26)
[    3.425064] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
[    3.431409] [drm] GuC firmware load skipped
[    3.433873] [drm] Initialized i915 1.6.0 20170123 for 0000:00:02.0 on minor 0
[    3.434000] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
[    3.434026] ACPI: Video Device [PEGP] (multi-head: yes  rom: yes  post: no)
[    3.434299] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:01/LNXVIDEO:00/input/input5
[    3.435361] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[    3.435523] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input6
[    4.803349] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

[   15.368189] nouveau 0000:01:00.0: bios: version 82.07.82.00.0a
[   15.371886] nouveau 0000:01:00.0: mxm: BIOS version 3.0

[   15.507872] nouveau 0000:01:00.0: priv: HUB0: 614900 00800000 (1f408200)
[   15.507873] nouveau 0000:01:00.0: fb: 2048 MiB GDDR5
[   15.514545] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 3c7e3c [ IBUS ]
[   15.567634] vga_switcheroo: enabled
[   15.570656] [TTM] Zone  kernel: Available graphics memory: 16405620 kiB
[   15.573639] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   15.576708] [TTM] Initializing pool allocator
[   15.579710] [TTM] Initializing DMA pool allocator

After that, I still got
[  1032.370] (WW) modeset(0): flip queue failed: Invalid argument
[  1032.370] (WW) modeset(0): Page flip failed: Invalid argument
[  1032.370] (EE) modeset(0): present flip failed


To your next question, what did I change? 
1) I went from 4.4 kernel to 4.11
2) I had nouveau blacklisted, and I unblacklisted it because I needed it to use HDMI or DP output which are only wired to the nvidia chip:
options nouveau modeset=1

Apparently this was a trigger for the problem though. I then tried:
blacklist nouveau
rebooted, and it stopped the spam in /var/log/Xorg.org
however, now I of course cannot use my external display ports anymore :(

And while the Xorg.log spam has stopped, chrome fails to initialize 3D it seems:
Jul 17 20:13:38 saruman kernel: [  318.426587] chrome[11887]: segfault at 208 ip 00007fc830af46f7 sp 00007fffd0bf5f20 error 4 in i965_dri.so[7fc83073d000+6a6000]
Jul 17 20:13:38 saruman kernel: [  318.653044] chrome[11942]: segfault at 208 ip 00007f027f80a6f7 sp 00007ffda713f840 error 4 in i965_dri.so[7f027f453000+6a6000]
Jul 17 20:13:38 saruman kernel: [  318.921247] chrome[12038]: segfault at 208 ip 00007f13059456f7 sp 00007ffef2fbcc80 error 4 in i965_dri.so[7f130558e000+6a6000]
Jul 17 20:14:01 saruman kernel: [  341.839095] chrome[12751]: segfault at 208 ip 00007f5285e866f7 sp 00007fff722a3ee0 error 4 in i965_dri.so[7f5285acf000+6a6000]
Jul 17 20:14:01 saruman kernel: [  342.209284] chrome[12804]: segfault at 208 ip 00007f4b29c266f7 sp 00007ffcd83d6fd0 error 4 in i965_dri.so[7f4b2986f000+6a6000]
Jul 17 20:14:02 saruman kernel: [  342.668782] chrome[12874]: segfault at 208 ip 00007f67204546f7 sp 00007fff8934fc90 error 4 in i965_dri.so[7f672009d000+6a6000]
I have libgl1-mesa-dri:amd64 13.0.3-1
Comment 3 Marc MERLIN 2017-07-18 03:48:11 UTC
Either way, it looks like by losing the dual modesetting driver setup I had, things are better in some ways (no more megabytes of spam logs), but I've now lost the ability to display on external monitors, and chrome seems to be unable to use 3D:

I upgraded to libgl1-mesa-dri:amd64      13.0.6-1+b2 
but it's still crashing when chrome starts:
[ 1167.844556] chrome[24112]: segfault at 208 ip 00007f244a4cf407 sp 00007ffd3efc86c0 error 4 in i965_dri.so[7f244a117000+6a7000]
[ 1168.136682] chrome[24168]: segfault at 208 ip 00007f102fd07407 sp 00007ffd7346e450 error 4 in i965_dri.so[7f102f94f000+6a7000]
[ 1168.407586] chrome[24251]: segfault at 208 ip 00007f3a0e1a5407 sp 00007ffc2658dd60 error 4 in i965_dri.so[7f3a0dded000+6a7000]

ii  google-chrome-beta         60.0.3112.50-1 

Before I disabled nouveau, and had those other issues, I didn't get this i965_dri.so crash in chrome.
chrome://gpu now reports this:
Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
CheckerImaging: Disabled
Flash: Software only, hardware acceleration unavailable
Flash Stage3D: Software only, hardware acceleration unavailable
Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
Compositing: Software only, hardware acceleration unavailable
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only, hardware acceleration unavailable
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated but at reduced performance
WebGL2: Unavailable

I guess on the plus side my CPU is fast enough that software rendering is now faster than the slow buggy hardware rendering I had before.

saruman:~$ vainfo 
libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.0.15)
vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.6.2
vainfo: Supported profile and entrypoints

saruman:~$ GL_DEBUG=y glxinfo | grep -E '(direct|renderer)'
direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) 
    GL_ARB_derivative_control, GL_ARB_direct_state_access, 
    GL_ARB_draw_elements_base_vertex, GL_ARB_draw_indirect, 
    GL_ARB_map_buffer_range, GL_ARB_multi_bind, GL_ARB_multi_draw_indirect, 

google-earth now crashes while it used to work.

however glmark2 went up from 919 to 1832, a huge performance boost.
This is all puzzling to say the least...
Comment 4 Ben Widawsky 2017-07-18 04:18:28 UTC
A bunch of the EINVAL returns don't tell you why it EINVAL'd from DRM_DEBUG, so that's unfortunate that we didn't hit an obvious one.

I'm not sure what's going on with Chrome. We'd need symbols with a backtrace.

Just to be clear, you have no module loaded for the nvidia hardware when these problems occur?
Comment 5 Marc MERLIN 2017-07-18 04:46:57 UTC
(In reply to Ben Widawsky from comment #4)
> A bunch of the EINVAL returns don't tell you why it EINVAL'd from DRM_DEBUG,
> so that's unfortunate that we didn't hit an obvious one.

ok.

> I'm not sure what's going on with Chrome. We'd need symbols with a backtrace.

yeah, possible with chromium but not google-chrome I guess.
 
> Just to be clear, you have no module loaded for the nvidia hardware when
> these problems occur?

I do not have the nvidia binary module at all if that's your question.
If you mean nouveau, I did have the nouveau module loaded with KMS in my original report, it's required for being to have this

saruman:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0xd0 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 1 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 1 name:modesetting

and then be able to do that:
xrandr --setprovideroutputsource 1 0

which allows me to mirror my display to the nouveau framebuffer and display it on HDMI or DP out.
As of my 2nd update, I now have blacklist nouveau and it made the modeset page flip errors go away, but in turn it also prevents me from mirroring my display onto the nvidia chip.
Comment 6 Ben Widawsky 2017-07-19 20:50:44 UTC
I want the mesa symbols, not chrome. Is it possible for you to do this?

You might want to file a new bug on the mesa issue separate from the modesetting issue when using noveau.
Comment 7 Ben Widawsky 2017-07-19 20:51:04 UTC
I want the mesa symbols, not chrome. Is it possible for you to do this?

You might want to file a new bug on the mesa issue separate from the modesetting issue when using noveau.
Comment 8 Marc MERLIN 2017-07-19 20:53:01 UTC
I'll see if I can open a new bug on mesa (as in get the data and open a bug with it)
Let's keep this bug on modesetting and not working along with nouveau KMS, agreed.
Comment 9 Marc MERLIN 2017-07-20 21:15:56 UTC
No luck getting debug symbols for mesa, it looks like up to date versions are not in debian :(  (installing debug packages for roll back to an older version of mesa)
saruman:~# aptitude install -t testing libwayland-egl1-mesa-dbg libegl1-mesa-dbg libegl1-mesa-drivers-dbg libgl1-mesa-dri-dbg libgl1-mesa-glx-dbg 
The following NEW packages will be installed:
  libegl1-mesa-dbg{b} libegl1-mesa-drivers-dbg{b} libgl1-mesa-dri-dbg{b} libgl1-mesa-glx-dbg{b} libwayland-egl1-mesa-dbg{b} 
0 packages upgraded, 5 newly installed, 0 to remove and 3131 not upgraded.
Need to get 54.5 MB of archives. After unpacking 59.0 MB will be used.
The following packages have unmet dependencies:
 libgl1-mesa-dri-dbg : Depends: libgl1-mesa-dri (= 10.3.2-1+deb8u1) but 13.0.6-1+b2 is installed
 libegl1-mesa-drivers-dbg : Depends: libegl1-mesa-drivers (= 10.3.2-1+deb8u1) but 10.6.3-1 is installed and it is kept back
 libegl1-mesa-dbg : Depends: libegl1-mesa (= 10.3.2-1+deb8u1) but 10.6.3-1 is installed and it is kept back
 libgl1-mesa-glx-dbg : Depends: libgl1-mesa-glx (= 10.3.2-1+deb8u1) but 13.0.6-1+b2 is installed
 libwayland-egl1-mesa-dbg : Depends: libwayland-egl1-mesa (= 10.3.2-1+deb8u1) but 10.6.3-1 is installed and it is kept back
Comment 10 Marcin Pertek 2017-08-02 15:43:14 UTC
Hardware: FirePro V4900 1GB + unused Intel iGPU, 2 screens
Xserver: 1.19.3
DDX: modesetting
Kernel: 4.12.4
libdrm: 2.4.80
mesa: 17.1.5

I just experienced the same message loop, accompanied by my screens going black. After a moment one screen came back and the other one only after performing a VT switch. In my case it seems to have been related to memory management.

---

[ 48110.479] (WW) modeset(0): flip queue failed: Cannot allocate memory
[ 48110.479] (WW) modeset(0): Page flip failed: Cannot allocate memory
[ 48110.479] (EE) modeset(0): present flip failed
[ 48110.479] (WW) modeset(0): flip queue failed: Cannot allocate memory
[ 48110.479] (WW) modeset(0): Page flip failed: Cannot allocate memory

the following part repeats:

[ 48110.611] (WW) modeset(0): flip queue failed: Invalid argument
[ 48110.611] (WW) modeset(0): Page flip failed: Invalid argument
[ 48110.611] (EE) modeset(0): present flip failed

---

It happened when I had a heavy IDE, 2 chromium and 2 firefox instances running, with lots of tabs open. Free RAM to overflow textures to was available though, if VRAM was exhausted.
Comment 11 maxiberta 2017-09-06 14:44:57 UTC
Same here on a Lenovo Thinkpad T460s with Intel HD Graphics 520, connected to an external Dell U2414H monitor via DP. Just switched from intel driver to modesetting. Seems to happen randomly, leaving the external monitor blank and lots of repeated logs.

First this:
[138540.200] (WW) modeset(0): flip queue failed: Cannot allocate memory
[138540.200] (WW) modeset(0): Page flip failed: Cannot allocate memory
[138540.200] (EE) modeset(0): present flip failed
[138540.200] (WW) modeset(0): flip queue failed: Cannot allocate memory
[138540.200] (WW) modeset(0): Page flip failed: Cannot allocate memory

And then lots of these:
[139986.728] (WW) modeset(0): flip queue failed: Device or resource busy
[139986.728] (WW) modeset(0): Page flip failed: Device or resource busy
[139986.728] (EE) modeset(0): present flip failed
[139986.745] (WW) modeset(0): flip queue failed: Device or resource busy
[139986.745] (WW) modeset(0): Page flip failed: Device or resource busy
[139986.745] (EE) modeset(0): present flip failed

Ftr, I'm able to recover with:
  $ xrandr --output DP-1-1 --off
  $ xrandr --output DP-1-1 --auto --right-of eDP-1

OS: Ubuntu 17.04 + Padoka Stable Mesa PPA
Hardware: Lenovo Thinkpad T460s with Intel HD Graphics 520
Xserver: 1.19.3
DDX: modesetting
Kernel: 4.10.0-33-generic
libdrm: 2.4.83
mesa: 17.2.0
Comment 12 Konstantin 2017-12-02 23:27:56 UTC
Same proplem?

Dez 03 00:10:53 konstantin-pc /usr/libexec/gdm-x-session[1833]: (WW) modeset(0): flip queue failed: Invalid argument
Dez 03 00:10:53 konstantin-pc /usr/libexec/gdm-x-session[1833]: (WW) modeset(0): Page flip failed: Invalid argument
Dez 03 00:10:53 konstantin-pc /usr/libexec/gdm-x-session[1833]: (EE) modeset(0): present flip failed

Intel i7-6700K (Skylake)
AMD RX 480
Fedora 27
Kernel 4.13.16-300.fc27.x86_64

Running dota 2 via steam using DRI_PRIME=1 and SDL_VIDEODRIVER=x11. If I switch to the "watch" tab in dota 2 the ui lags a lot the error messages occur in my systemd journal.

$ dnf list installed | egrep 'mesa|drm|amd|intel|radeon'
libdrm.i686                            2.4.88-1.fc27            @updates        
libdrm.x86_64                          2.4.88-1.fc27            @updates        
libdrm-devel.x86_64                    2.4.88-1.fc27            @updates        
libva-intel-driver.i686                1.8.3-2.fc27             @rpmfusion-free 
libva-intel-driver.x86_64              1.8.3-2.fc27             @rpmfusion-free 
mesa-dri-drivers.i686                  17.2.4-2.fc27            @updates        
mesa-dri-drivers.x86_64                17.2.4-2.fc27            @updates        
mesa-filesystem.i686                   17.2.4-2.fc27            @updates        
mesa-filesystem.x86_64                 17.2.4-2.fc27            @updates        
mesa-libEGL.x86_64                     17.2.4-2.fc27            @updates        
mesa-libEGL-devel.x86_64               17.2.4-2.fc27            @updates        
mesa-libGL.i686                        17.2.4-2.fc27            @updates        
mesa-libGL.x86_64                      17.2.4-2.fc27            @updates        
mesa-libGL-devel.x86_64                17.2.4-2.fc27            @updates        
mesa-libGLES.x86_64                    17.2.4-2.fc27            @updates        
mesa-libGLES-devel.x86_64              17.2.4-2.fc27            @updates        
mesa-libGLU.x86_64                     9.0.0-13.fc27            @fedora         
mesa-libgbm.x86_64                     17.2.4-2.fc27            @updates        
mesa-libgbm-devel.x86_64               17.2.4-2.fc27            @updates        
mesa-libglapi.i686                     17.2.4-2.fc27            @updates        
mesa-libglapi.x86_64                   17.2.4-2.fc27            @updates        
mesa-libwayland-egl.i686               17.2.4-2.fc27            @updates        
mesa-libwayland-egl.x86_64             17.2.4-2.fc27            @updates        
mesa-libwayland-egl-devel.x86_64       17.2.4-2.fc27            @updates        
mesa-libxatracker.x86_64               17.2.4-2.fc27            @updates        
teamd.x86_64                           1.27-3.fc27              @fedora         
xorg-x11-drv-intel.x86_64              2.99.917-31.20171025.fc27
Comment 13 Konstantin 2017-12-02 23:32:08 UTC
Created attachment 135883 [details]
drm.debug=0x1e log_buf_len=1M

These error messages are seen in the systemd journal when switching to the "watch" tab in the dota 2 client/game ran via steam.

I didn't have this issue when I first installed Fedora 27 1-2 months ago. It must have started in last few days, but I can't tell if a Fedora or Steam update is responsible for this.

The game itself is playable as usual most of the time, but sometimes becomes very laggy.
Comment 14 Konstantin 2017-12-07 20:33:36 UTC
After some updates to both fedora and dota 2 the lagging is now gone, but the error messages

Dez 07 19:10:24 konstantin-pc /usr/libexec/gdm-x-session[1931]: (WW) modeset(0): flip queue failed: Invalid argument
Dez 07 19:10:24 konstantin-pc /usr/libexec/gdm-x-session[1931]: (WW) modeset(0): Page flip failed: Invalid argument
Dez 07 19:10:24 konstantin-pc /usr/libexec/gdm-x-session[1931]: (EE) modeset(0): present flip failed

remain.
Comment 15 GitLab Migration User 2018-12-13 18:09:19 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/24.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.