Created attachment 23881 [details] config used i915: playing video via XVideo extension makes the screen flicker The video doesn't seems to appear at all. But the whole screen starts to flicker. Restarting the X server via "pkill gdm", seems to start the X server normally again. But I still cannot play videos.
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.