Bug 14670

Created attachment 23882 [details]
dmesg

Created attachment 23883 [details]
Xorg log where I tried to play a video

Created attachment 23884 [details]
Xorg log after restarting gdm

Oh! Strange! Starting a gnome-terminal. Enter "su". Start "powertop" as root. This makes the X server also flicker like when I want to play a video! Strange, isn't it?

You say it's a regression, but since which kernel version?  2.6.31?

Thanks.

2.6.31.6 works fine.

booting the 2.6.32-rc8 kernel with option "nomodeset" makes the videos and powertop work again.

bisect to:

b42d4c5c6a872815d711e5d51a600f5122c38eee is the first bad commit
commit b42d4c5c6a872815d711e5d51a600f5122c38eee
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:04 2009 -0700

    drm/i915: use ACPI LID status for LVDS ->detect hook
    
    We can't load or hotplug detect LVDS like we can other outputs, but if
    there's a lid device present we can use it as a proxy.  This allows the
    LFP state to be determined at ->detect time, making configurations
    requiring manual intervention today "just work" assuming the lid device
    status is correct.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

:040000 040000 e8860db5d490afe490ea66083c57a639874fcafa e004d6ea8d9f32c812a28f1ec59e5068db49ad85 M	drivers

Reverting above commit against 2.6.32-rc8 makes the flickering go away.

Miscreants added to cc ;)

Guys, it's a post-2.6.31 regression - fairly highpri.

Very strange... that commit shouldn't have affected the flickering problem at all, but we do have some other weird issues surrounding it.

Can you attach your dmesg from a kernel with the drm module param debug set to 6?  That should let me see your FIFO watermark settings, which are usually responsible for this sort of problem.

Created attachment 23987 [details]
kernel log with drm.debug=6

Arg, debug=6 was wrong, sorry about that.  Can you use debug=7 instead?  The output from a fresh boot after X starts should be good enough.

Created attachment 24000 [details]
kernel log with drm.debug=7

Are you sure that bisect was correct?  Can you try this patch and see if it helps?

--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2450,7 +2450,7 @@ static void igd_enable_cxsr(struct drm_device *dev, unsign
  * A value of 5us seems to be a good balance; safe for very low end
  * platforms but not overly aggressive on lower latency configs.
  */
-const static int latency_ns = 5000;
+const static int latency_ns = 7000;
 
 static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
 {

(In reply to comment #14)
> Are you sure that bisect was correct? 

Who should I know? Reverting above commit at least make the symptoms of an sluggish system/of the flickering go away!

> Can you try this patch and see if it
> helps?
> 
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2450,7 +2450,7 @@ static void igd_enable_cxsr(struct drm_device *dev,
> unsign
>   * A value of 5us seems to be a good balance; safe for very low end
>   * platforms but not overly aggressive on lower latency configs.
>   */
> -const static int latency_ns = 5000;
> +const static int latency_ns = 7000;
> 
>  static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
>  {

No, above patch doesn't help. Still see the flickering while playing a video. System feels still sluggish with above patch applied.

Can you post a video of the flicker you're seeing?  I want to see if it's the kind I'm thinking of...

Created attachment 24032 [details]
Flickering on video. System reacts very sluggish.

Bad quality video. But I hope you get an impression.

perf top after starting a video in gnome:

------------------------------------------------------------------------------
   PerfTop:    7186 irqs/sec  kernel:52.8% [100000 cycles],  (all, 1 CPUs)
------------------------------------------------------------------------------

             samples    pcnt   kernel function
             _______   _____   _______________

            23294.00 - 52.5% : delay_tsc
             1820.00 -  4.1% : drm_clflush_pages
             1774.00 -  4.0% : read_hpet
             1548.00 -  3.5% : rb_next
             1437.00 -  3.2% : native_flush_tlb_single
              783.00 -  1.8% : idr_find
              736.00 -  1.7% : i915_gem_execbuffer
              679.00 -  1.5% : copy_from_user
              634.00 -  1.4% : copy_to_user
              545.00 -  1.2% : sysenter_past_esp
              441.00 -  1.0% : avc_has_perm_noaudit
              401.00 -  0.9% : alloc_vmap_area
              382.00 -  0.9% : drm_ioctl
              308.00 -  0.7% : file_has_perm
              294.00 -  0.7% : kref_put
WARNING: failed to keep up with mmap data.  Last read 105 msecs ago.

Now the strange thing: Switching to virtual console 2 and back into X, makes the flickering stop and the video starts to play normally!

perf top output: playing a video after switching to VT and back to X:
------------------------------------------------------------------------------
   PerfTop:    3922 irqs/sec  kernel:28.3% [100000 cycles],  (all, 1 CPUs)
------------------------------------------------------------------------------

             samples    pcnt   kernel function
             _______   _____   _______________

             2499.00 - 16.0% : delay_tsc
             1591.00 - 10.2% : read_hpet
             1423.00 -  9.1% : drm_clflush_pages
              822.00 -  5.3% : native_flush_tlb_single
              387.00 -  2.5% : rb_next
              237.00 -  1.5% : avc_has_perm_noaudit
              234.00 -  1.5% : unix_poll
              221.00 -  1.4% : sysenter_past_esp
              220.00 -  1.4% : fget_light
              202.00 -  1.3% : copy_from_user
              201.00 -  1.3% : do_sys_poll
              196.00 -  1.3% : kunmap_atomic
              187.00 -  1.2% : copy_to_user
              169.00 -  1.1% : i915_gem_execbuffer
              165.00 -  1.1% : idr_find

Created attachment 24048 [details]
function trace

function trace of 
a) start playing a video in totem
b) flickering begins
c) switch to VT2 and back to X
d) flickering stops and video starts to play normally

Yeah, looks like underruns probably... thanks for confirming.

Ah, the fact that a VT switch fixes it is a good clue... Means we do something in the mode set path in X or the kernel that updates the appropriate regs but we fail to do it at resume time (though theoretically we do a full mode set at resume too... hmmm).

Maybe related to this thread:

http://lkml.org/lkml/2009/12/8/164

The bug still exists in 2.6.33-rc1. Is there a register dump tool available?

On Tuesday 29 December 2009, Thomas Meyer wrote:
> Am Dienstag, den 29.12.2009, 16:28 +0100 schrieb Rafael J. Wysocki:
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=14670
> > Subject             : i915: playing video via XVideo extension makes the
> screen flicker
> > Submitter   : Thomas Meyer <thomas@m3y3r.de>
> > Date                : 2009-11-23 13:15 (37 days old)
> 
> Need to boot 2.6.32.2 with "nomodeset" option to make the above bug go
> away. Without "nomodeset" option, i.e. the default for intel kms, the
> system behaves very strangley/sluggish under 2.6.32.2.
> 
> So yes, please still list this bug.

Problem still exists in 2.6.32.3 and 2.6.33-rc3-00097-g2c1f189, that contains this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cda9d05c499093c67b4a376a15009923acc2127a

The above commit removes the render reclock support, that ought to fix a common kind of problem encountered on i915 hardware, but not on my machine.

Still need to boot with "nomodeset" to have a workable system.

First-Bad-Commit : b42d4c5c6a872815d711e5d51a600f5122c38eee
References : http://lkml.org/lkml/2010/1/11/150

As told in :
http://bugzilla.kernel.org/show_bug.cgi?id=14670#c22
http://bugzilla.kernel.org/show_bug.cgi?id=14781#c13

reverting http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=181a5336d6cc836f05507410d66988c483ad0154
fixed the issue while http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cda9d05c499093c67b4a376a15009923acc2127a
does not.

I have flickering then hang on a color (aall the screen is filled with this color).

The most significant change the revert produce is dev_priv->render_reclock_avail = true;
would not be set if SUPPORTS_EDP(dev) is false and driver->dual_frequency is true.

Note that the issue only affect the LVDS . When I have a display on the second output (CRTS) the crts is never affected (but the LVDS also flicker then ends up hanging on one color).

On Wednesday 27 January 2010, Thomas Meyer wrote:
> Am Mittwoch, den 27.01.2010, 09:59 -0800 schrieb Jesse Barnes:
> > On Sun, 24 Jan 2010 23:22:54 +0100 (CET)
> > "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > 
> > > This message has been generated automatically as a part of a report
> > > of regressions introduced between 2.6.31 and 2.6.32.
...
> > this one may also be fixed by David's patch if -rc5 doesn't already fix
> > it.
> 
> Still see this error with -rc5. But I guess this is very likely an
> ACPI/BIOS error. I have an Acer 1810T (1410T in US of A) with BIOS
> version 3302. Can someone with the same hardware but different (i.e.
> newer BIOS version - version 3303) confirm this bug?
> 
> When the flickering occurs, switching VTs back and forth makes the
> problem go away!

Assuming David John's patch doesn't fix this (http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-01/msg09832.html), I wonder if this helps:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 6ebd89d..aa9a9c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3758,7 +3758,7 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_de
        return mode;
 }
 
-#define GPU_IDLE_TIMEOUT 500 /* ms */
+#define GPU_IDLE_TIMEOUT 5000 /* ms */
 
 /* When this timer fires, we've been idle for awhile */
 static void intel_gpu_idle_timer(unsigned long arg)

We'll also need to make sure we don't enable self-refresh in the idle timer.

Either David John's patch nor your patch fixes the problem for me.

I posted my patch to lkml: http://lkml.org/lkml/2010/2/2/360
Which fixes the flickering and sluggish system behaviour for me.

And I see Eric applied it, thanks.

Fixed by commit 67026e03244d76b8f1fa725b079d4182fe8910aa.