linux-kernel - Re: [Bug #14670] i915: playing video via XVideo extension makes the screen flicker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 13 Jan 2010 22:48:40 +0100
From:	Thomas Meyer <thomas@...3r.de>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Eric Anholt <eric@...olt.net>
Subject: Re: [Bug #14670] i915: playing video via XVideo extension makes
 the screen flicker

Am Dienstag, den 12.01.2010, 09:57 -0800 schrieb Jesse Barnes:
> On Tue, 12 Jan 2010 18:43:09 +0100
> Thomas Meyer <thomas@...3r.de> wrote:
> 
> > Am Montag, den 11.01.2010, 11:19 -0800 schrieb Jesse Barnes:
> > > On Mon, 11 Jan 2010 20:03:57 +0100
> > > Thomas Meyer <thomas@...3r.de> wrote:
> > > 
> > > > 
> > > > 
> > > > Am 11.01.2010 um 17:55 schrieb Jesse Barnes
> > > > <jbarnes@...tuousgeek.org>:
> > > > 
> > > > > On Mon, 11 Jan 2010 17:53:04 +0100
> > > > > Thomas Meyer <thomas@...3r.de> wrote:
> > > > >
> > > > >> Am Sonntag, den 10.01.2010, 23:56 +0100 schrieb Rafael J.
> > > > >> Wysocki:
> > > > >>> This message has been generated automatically as a part of a
> > > > >>> report of regressions introduced between 2.6.31 and 2.6.32.
> > > > >>>
> > > > >>> The following bug entry is on the current list of known
> > > > >>> regressions introduced between 2.6.31 and 2.6.32.  Please
> > > > >>> verify if it still should be listed and let me know (either
> > > > >>> way).
> > > > >>>
> > > > >>
> > > > >> Yes, still should be listed.
> > > > >>
> > > > >> 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.
> > > > >
> > > > > Does this patch prevent the flicker?
> > > > 
> > > > By the way: how often and in what interval is the function   
> > > > intel_lvds_detect called?
> > > > 
> > > > How long will/can the function acpi_lid_open take to complete?
> > > > Maybe some acpi interpretation takes really long? Is this
> > > > possible?
> > > > 
> > > > Would this explain the flickering?
> > > 
> > > It should only be called when a client requests the connection
> > > status (e.g. xrandr or the GNOME display applet).
> > 
> > how to check how often this function is called and it's duration? is
> > the function tracer capable of this?
> 
> Yeah, the function tracer should be able to do it (though I don't know
> how to use it offhand, maybe through the perf tool?).  Or you could
> just add some DRM_ERROR lines. :)


After recompiling the kernel without optimize for size I could use the
function graph tracer and set the function to "intel_lvds_detect".

Here is an example of the output:

 0)   0.365 us    |                up();
 0)   1.092 us    |              }
 0)   1.824 us    |            }
 0)   2.486 us    |          }
 0)   0.376 us    |          kfree();
 0) ! 9759.012 us |        }
 0) ! 9759.813 us |      }
 0) ! 9761.096 us |    }
 0) ! 9764.483 us |  }
 0)               |  intel_lvds_detect() {
 0)               |    acpi_lid_open() {
 0)               |      acpi_evaluate_integer() {
 0)               |        acpi_evaluate_object() {
 0)               |          acpi_os_allocate_zeroed() {
 0)               |            __kmalloc() {
 0)   0.366 us    |              get_slab();
 0)   0.336 us    |              _cond_resched();
 0)   0.396 us    |              memset();
 0)   2.796 us    |            }
 0)   3.447 us    |          }
 0)   0.531 us    |          acpi_ns_validate_handle();

So the call to "intel_lvds_detect" seems to take around 10000us, i.e.
10ms (I guess this is long), thanks to heavy ACPI interpretation.

So the question still is: Why is the drm_ioctl (that in turn calls
intel_lvds_detect) called so often by Xorg?

greets
thomas


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/