Am Dienstag, den 12.01.2010, 09:57 -0800 schrieb Jesse Barnes: > On Tue, 12 Jan 2010 18:43:09 +0100 > Thomas Meyer <thomas@xxxxxxxx> 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@xxxxxxxx> wrote: > > > > > > > > > > > > > > > Am 11.01.2010 um 17:55 schrieb Jesse Barnes > > > > <jbarnes@xxxxxxxxxxxxxxxx>: > > > > > > > > > On Mon, 11 Jan 2010 17:53:04 +0100 > > > > > Thomas Meyer <thomas@xxxxxxxx> 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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
