[Bug 97139] New: i915: Intermittent short system stutter / lag affecting graphics output; bisected to commit f8d03ea

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=97139

            Bug ID: 97139
           Summary: i915: Intermittent short system stutter / lag
                    affecting graphics output; bisected to commit f8d03ea
           Product: DRI
           Version: DRI git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: t.ambetarak at gmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 125428
  --> https://bugs.freedesktop.org/attachment.cgi?id=125428&action=edit
dmesg output + miscellanious other info about the system

First of all, apologies, this bug was tested against the latest mainline
kernel, not the DRM kernel - this was before I realized i915 bugs should be
submitted to freedesktop.org. I'm hoping it will still be useful. 

Description
-----------

Once in a while (several times per minute) there is a short system stutter or
lag (lasting for less than a second, but clearly noticable).  Everything
graphics-related is  affected by the lag, e.g. the mouse cursor and video
playback. When a video is playing in VLC, frames are dropped at the same time
as the mouse cursor hangs when moving it around; at the same time the glxgears
test application stutters. Audio output is not affected. Notes:

- Using or not using the X Intel video driver (xf86-intel-video on Arch Linux)
  does not matter.
- Turning compositing on or off does not matter (either the XFCE compositor or
  xcompmgr).
- Applying the latest CPU microcode updates or not does not matter.

Running strace on glxgears shows that some recvmsg syscalls take a very long
time, this is when the lag happens (~0.24s):

0.000053 poll([{fd=3, events=POLLIN}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
0.237675 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"f\0f\34\2\0\0\0\2\0
\3\1\0\0\0\320\0r\214\0\0\0\0\216\v\0\0j\t\0\0", 4096}], msg_controllen=0,
msg_flags=0}, 0) = 32

FD 3 is the X11 socket ("/tmp/.X11-unix/X0").

I have isolated the problem to kernel commit f8d03ea, which changed HDMI
hotplug detection to take at most 80 ms. This seems to be too much on my
hardware and is causing issues. The original value was 30 ms. Changing it to
10 ms eliminates the problem completely for me (resolution tested against
commit 1a81a8f). It seems that the proper resolution would be to rewrite the
hotplug detection to eliminate blocking.

Environment
-----------

The general hardware / software environment is: an HP laptop with Intel i5
CPU, integrated graphics. 4.12, Arch Linux fully up to date, XFCE 4.12. A Dell
U2410 external monitor is attached via DisplayPort.

$ uname -m
x86_64

$ uname -r
4.7.0-ARAK-06537-g1a81a8f

How to reproduce
----------------

Can be tested by running a video in VLC that is known to not overwhelm
the CPU(s), passing the -vvv flags. On a kernel affected by the bug, several
messages at a time appear in the output about frames being dropped ("picture
is too late to be displayed", once or twice per minute). At the same time, the
mouse cursor stutters, if mouse is being moved.

Attached are dmesg output and other possibly useful information.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160729/552513bd/attachment.html>