How about if you watch 'sudo perf top' and see what is most active whilst the most lags?

Top shows nothing special - logs in attachment.

Acceleration SNA of course.

I don't have problems, when I run it in virtual desktop (as window). Problems are only on fullscreen.

Mouse stutters always in real game. Not more or less.


Crash on closing game is also problem. Try to shutdown on running game also freezes computer.

Created attachment 68864 [details]
log from top

Hmm, a scary number of times that Xorg is stuck in 'D' -- meaning that it is blocked from running due (normally) to IO.

Can you attach a normal /var/log/Xorg.0.log? Grabbing a stack trace whilst Xorg is in 'D' would be fantastic, or maybe just enable WCHAN output in top.

Xorg log in attachment. My previous logs were much larger, so I wrote about little space in my disk.

Created attachment 68867 [details]
Xorg.0.log

Just to be sure, do you also see the lag when you compile without --enable-debug=full?

Yes. I always compile drivers without debug at first. 
./configure --prefix=/usr

Then, if something doesn't work, I create debug-version.
./configure --prefix=/usr --enable-debug=full

Log from top was also without debug drivers.

Ok, can you enable WCHAN reporting in top (press f, highlight WCHAN and hit space) and grab a few samples when Xorg is stuck in 'D'. Or 'sudo cat /proc/`pidof X`/stack'

Created attachment 68872 [details]
top with WCHAN

Created attachment 68873 [details]
cat /proc/`pidof X`/stack

Ah, so the 'D' is due to the uninterruptible wait for i915_gem_object_pin_to_display_plane(). Except that it should not block here...

The alternative is i915_gem_object_get_fence(), but again there should be no reason for a long wait there.

Can you please install 'trace-cmd' and run 'sudo trace-cmd record -e i915 -e drm' whilst it lags, and then attach the output of trace-cmd report.

trace-cmd is available here: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git

Created attachment 68875 [details]
trace-cmd.log.tar.bz2

The culprit seems to be that we wait for mesa for very long periods of time to complete it rendering, during which time we will not even update the mouse. It looks like you need:

commit 79158103bf20c9ff55204ceb78a5773f422b03be
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 23 11:13:58 2012 +0100

    drm/i915: Make the lock for pageflips interruptible
    
    As we take the struct_mutex lock to access the command-stream, there is
    a possibility that we may need to wait for a GPU hang and so should make
    the lock both interruptible and error-checking.
    
    References: https://bugs.freedesktop.org/show_bug.cgi?id=50069
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

and

commit 3236f57a0162391f84b93f39fc1882c49a8998c7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:35:09 2012 +0100

    drm/i915: Use a non-blocking wait for set-to-domain ioctl
    
    The principal use for set-to-domain is for userspace to serialise
    operations with a particular buffer, for example to maintain coherency
    with a CPU map or to ratelimit its rendering by waiting on all previous
    operations before continuing. As such we tend to hold the struct_mutex
    for long periods during the synchronisation and so cause contention
    issues with other users of the graphics device, even for independent
    operations as memory management. An example is the contention between
    compiz and X which causes jitter in the display and a drop in peak
    throughput.
    
    The ultimate solution would be a set of fine grained locks and lockless
    operations, but an intermediate step is to first attempt the
    synchronisation for set-to-domain without holding the mutex. This
    introduces a number of race conditions, so we limit it use to the ioctl
    periphery where we have no dependent state and can safely complete with
    a locked synchronisation afterwards.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

would it be possible for you to test a 3.7-r2 kernel (or perhaps drm-intel-next)?

Though that doesn't explain why this feels like a regression from -intel-2.20.9. If you can bisect -intel, that may help us to find an alternative solution.

git bisect good 2.20.9
git bisect bad 2.20.10



3e770f09dbe76287293fea0a8a1f231885aa1c1f is the first bad commit
commit 3e770f09dbe76287293fea0a8a1f231885aa1c1f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Oct 3 13:00:25 2012 +0100

    sna/dri: Delay the deactivation of the pageflipping
    
    As we need to clflush the scanout buffer as we return it to the bo cache
    on SNB+, it is costly to terminate the pageflipping as soon as we drop a
    frame as mesa often fails to keep up to the vrefresh rate.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

:040000 040000 c52079be324edc5d4daa9c2d966115d028997d1c 4842f09c9467a1beb1a64b91d712b0296fd2f0bf M	src



It also causes the crashing/freezing system on closing the game. I think in changing resolution.

Testing newest kernel is hard, because lastest in my repos is 3.5.5. Configuration and compilation take a lot of time. I will see on ubuntu repositories, maybe there is recent version.

Hmm, yes, given your kernel that will actually impair responsiveness due to the lock contention.

Not seen a crash with modeswitching whilst pageflipping, care to attach gdb and grab a bt? Meanwhile, one of the ~kernel-ppa/mainline will carry the pair of patches that I think you need.

I should run gdb startx? I'm not sure if I understand.

I will try new kernel if it will be in repository.

Running X under gdb is easiest using a second computer. So don't worry if you can't, just attach an Xorg.log with the crash info and I may ask you translate some of the stacktraces.

For the kernel package, try http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/current/

I tried install:
linux-image-3.6.0-994-generic_3.6.0-994.201210200406_i386.deb

But on booting I have information about problems with calibration, then resolution doesn't change and I can't do anything.

Computer also freezed when I create Xorg log from comment 6. I think it will also freeze when I will run gdb, so I won't read bt log. And I don't have other computer to run X from it.

(In reply to comment #21)
> I tried install:
> linux-image-3.6.0-994-generic_3.6.0-994.201210200406_i386.deb
> 
> But on booting I have information about problems with calibration, then
> resolution doesn't change and I can't do anything.

Ok, that's bizarre and I'm not sure what to suggest. Maybe just keep an eye out for a mainline kernel through the usual channels? Or some other ppa?
 
> Computer also freezed when I create Xorg log from comment 6. I think it will
> also freeze when I will run gdb, so I won't read bt log. And I don't have
> other computer to run X from it.

Running X under gdb is quite complicated due to gdb trapping the signals that X uses to switch VT and so you lose control of machine.

I'm satisfied that this the lock contention judging by the trace you provided. It would be fantastic if you were able to confirm that by finding a 3.7 kernel to test. Please do report back when you get the chance, thanks.

I tested it few minutes ago with kernel 3.7-rc2. Everything works, system doesn't crash. I think you can close. Thank you for your suggestion with recent kernel.