Created attachment 105286 [details] intel_reg_dumper output Graphics: Sandy Bridge Kernel: 3.16 Mesa: 10.2.5 Distribution: Debian (unstable) Driver: 2.99.914 This bug manifests itself in different, although related ways. For example, in hexchat lines do not get drawn correctly on the first time, there is some delay until the line is drawn completely (this happens in about 10% of the cases): https://plus.google.com/+JulianAndresKlode/posts/RkE3gpX8tiF In a terminal, there are some hangs when using ncurses-based applications, and even when entering normal commands it can hang. The bug does not occur all the time. I'm running under GNOME Shell. I'll try to see if it happens if I run in non-compositing environment.
Created attachment 105288 [details] Xorg log file extracted from journal
Created attachment 105289 [details] Running under twm (non-compositing) Here's a video running hexchat under twm. You probably cannot see anything here on the video, but I can tell you there is a minor glitch as well, but it's apparently to fast to capture at 30 frames per second.
Created attachment 105290 [details] dmesg.txt Here's the dmesg. Not sure about the segmentation faults at the end, they are not noticeable at all (and ignore the marco trap)
Under twm, is should only render text to the screen ~60fps (i.e. flushes out to the screen are batched based on the vblank interval). There are a lot of other heuristics that try to keep the GPU busy, but at most rendering should only be delayed by at most 16ms. Hopefully that is the delay you see there. That definitely doesn't explain the major delay under gnome-shell.
First try with Section "Device" Identifier "intel" Option "DRI" "2" EndSection
Oh, and be sure not to enable fbc. That will also cause delays in rendering.
BTW, I think I have a more sensible way to reproduce this reliably than to run hexchat: Editing files with nano (such as the dmesg.txt) in gnome-terminal is slowed down a lot. For example, if you delete a line, it might take a second for it to be deleted, same if you insert stuff via Ctrl+Shift+V or enter newlines. Not always though, but in the majority of cases. (In reply to comment #5) > First try with > > Section "Device" > Identifier "intel" > Option "DRI" "2" > EndSection And this seems to fix the issue. (In reply to comment #6) > Oh, and be sure not to enable fbc. That will also cause delays in rendering. I removed all i915-related entries from the kernel command line which did not make a difference.
(In reply to comment #7) > (In reply to comment #6) > > Oh, and be sure not to enable fbc. That will also cause delays in rendering. > > I removed all i915-related entries from the kernel command line which did > not make a difference. Whilst you are testing, could you compare twm with/without fbc? (Just getting feedback, some people report bad delays with fbc, x11perf is often upset etc.)
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > Oh, and be sure not to enable fbc. That will also cause delays in rendering. > > > > I removed all i915-related entries from the kernel command line which did > > not make a difference. > > Whilst you are testing, could you compare twm with/without fbc? (Just > getting feedback, some people report bad delays with fbc, x11perf is often > upset etc.) Performance seems the same. I never had any issues with fbc or any other of those options I use normally: i915.i915_enable_fbc=1 i915.i915_enable_rc6=7 i915.lvds_downclock=1 All seem to work fine.
Your hardware doesn't support rc6+ or rc6++, so please don't use anything other than rc6=1 (we allow it for testing, but the hardware has not been validated for those modes). fbc=1 has a number of known issues, that includes a deadlock when changing outputs (so caveat lector). lvds_downclock depends upon having a downclock mode available and may cause flickering/headaches.
(In reply to comment #10) > Your hardware doesn't support rc6+ or rc6++, so please don't use anything > other than rc6=1 (we allow it for testing, but the hardware has not been > validated for those modes). fbc=1 has a number of known issues, that > includes a deadlock when changing outputs (so caveat lector). lvds_downclock > depends upon having a downclock mode available and may cause > flickering/headaches. RC6+ is enabled by default already. Booting on kernel without any i915 options gives: Aug 26 17:18:49 jak-x230 kernel: [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off But apart from I just noticed that the kernel parameters do not work anymore anyway, since the i915_ prefix was dropped, so they are ignored currently. So I guess I'll just drop the options now since I did not use them recently anyway.
Oops, yes of course you have rc6+ since it is an Ivybridge not SandyBridge. :)
(In reply to comment #12) > Oops, yes of course you have rc6+ since it is an Ivybridge not SandyBridge. > :) Ouch, my fault. I miscounted.
*** This bug has been marked as a duplicate of bug 81551 ***
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.