[Intel-gfx] Continuous EDID probing (was: Re: [PATCH] Manage PIPESTAT pending interrupt values to unblock vblank interrupts)

Steven J Newbury steve at snewbury.org.uk
Sat Nov 8 13:34:44 CET 2008


On Sat, 2008-11-08 at 12:28 +0000, Steven J Newbury wrote:
> On Sat, 2008-11-08 at 03:07 +0000, Steven J Newbury wrote:
> > On Fri, 2008-11-07 at 22:00 +0000, Steven J Newbury wrote:
> > > On Fri, 2008-11-07 at 21:44 +0000, Steven J Newbury wrote:
> > > > On Fri, 2008-11-07 at 20:45 +0000, Steven J Newbury wrote:
> > > > > On Fri, 2008-11-07 at 11:11 -0800, Eric Anholt wrote:
> > > > > > On Fri, 2008-11-07 at 14:01 +0000, Steven J Newbury wrote:
> > > > 
> > > > > 
> > > > > > > This is possibly also related to the massive slowdown I get X uses 20%+
> > > > > > > CPU constantly and continually probes DDC, when I switch to battery,
> > > > > > > this I had expected to be fixed by the recent patch removing ACPI event
> > > > > > > handling, but strangely it still occurs.
> > > > > > 
> > > > > > You're the only person I've heard of with this problem.  You'll need to
> > > > > > figure out what's causing it.  We still handle ACPI events, it was just
> > > > > > an internal timer potentially firing off DDC that was removed.
> > > > > > 
> > > > > I wonder if it's the VBIOS triggering continuous events?  It may have
> > > > > started happening when I updated to revision A13 (the latest) of the
> > > > > Dell D830 BIOS.  Perhaps I'm the only tester with a D830?
> > > > > 
> > > > > Any idea how I could track this down?
> > > > > 
> > > > 
> > I've discovered this behaviour only occurs when gnome-power-manager
> > and/or gnome-settings-daemon are running.  I'm guessing this started
> > after the work to stop the flicker people were experiencing when
> > starting GTK apps, although I never suffered previously from that bug
> > myself.  So this could be a GTK bug?  I'm using gtk+-2.14.4.
> > 
> Here's a gdb backtrace from g-p-m while this is occurring:
> 
> #0  0x00007f4b8dcaaa12 in select () from /lib/libc.so.6
> #1  0x00007f4b8fe3da95 in _xcb_conn_wait (c=0x1cbf350, 
>     cond=<value optimized out>, vector=0x0, count=0x0) at xcb_conn.c:283
> #2  0x00007f4b8fe3f4d4 in xcb_wait_for_reply (c=0x1cbf350,
> request=4264, 
>     e=0x7fffa1622ec0) at xcb_in.c:377    <--- not the reply it expects?
> #3  0x00007f4b900a5ac3 in _XReply (dpy=0x1cbe570, rep=0x7fffa1622f60,
> extra=0, 
>     discard=0) at xcb_io.c:454
> #4  0x00007f4b93714be0 in XRRGetScreenResources (dpy=0x1cbe570,
> window=128)                     <--- gets called repeatedly within loop
>     at XrrScreen.c:81
> #5  0x0000000000424fe9 in gpm_brightness_xrandr_update_cache (
>     brightness=0x1eb05e0) at gpm-brightness-xrandr.c:616
> #6  0x00007f4b8e242468 in IA__g_closure_invoke (closure=0x1eb8890, 
>     return_value=0x0, n_param_values=1, param_values=0x1f1e360, 
>     invocation_hint=0x7fffa16231b0) at gclosure.c:767
> #7  0x00007f4b8e259181 in signal_emit_unlocked_R (node=0x1ccc940,
> detail=0, 
>     instance=0x1cd0060, emission_return=0x0,
> instance_and_params=0x1f1e360)
>     at gsignal.c:3244
> #8  0x00007f4b8e25a668 in IA__g_signal_emit_valist (instance=0x1cd0060, 
>     signal_id=<value optimized out>, detail=0, var_args=0x7fffa16233c0)
>     at gsignal.c:2977
> #9  0x00007f4b8e25a9ba in IA__g_signal_emit_by_name
> (instance=0x1cd0060, 
>     detailed_signal=<value optimized out>) at gsignal.c:3071
> #10 0x00007f4b91e4d215 in gdk_event_translate (display=<value optimized
> out>, 
> ---Type <return> to continue, or q <return> to quit---
>     event=0x1f069d0, xevent=0x7fffa1623680, 
>     return_exposes=<value optimized out>) at gdkevents-x11.c:2115
> #11 0x00007f4b91e4e687 in _gdk_events_queue (display=0x1ccf000)
>     at gdkevents-x11.c:2299
> #12 0x00007f4b91e4ea5e in gdk_event_dispatch (source=<value optimized
> out>, 
>     callback=0x7fffa1622d50, user_data=0x7fffa1622cd0) at
> gdkevents-x11.c:2359
> #13 0x00007f4b8df7eccb in g_main_dispatch (context=0x1cd7e00) at
> gmain.c:2144
> #14 0x00007f4b8df80a8d in g_main_context_iterate (context=0x1cd7e00,
> block=1, 
>     dispatch=1, self=<value optimized out>) at gmain.c:2697
> #15 0x00007f4b8df81015 in IA__g_main_loop_run (loop=0x1f590c0) at
> gmain.c:2986
> #16 0x00000000004283d0 in main (argc=1, argv=0x7fffa1623b98) at
> gpm-main.c:253
> 
This is another backtrace from g-p-m while the behaviour continues:

#0  0x00007f4b8dcaaa12 in select () from /lib/libc.so.6
#1  0x00007f4b8fe3da95 in _xcb_conn_wait (c=0x1cbf350, 
    cond=<value optimized out>, vector=0x0, count=0x0) at xcb_conn.c:283
#2  0x00007f4b8fe3f4d4 in xcb_wait_for_reply (c=0x1cbf350,
request=4408, 
    e=0x7fffa16233e0) at xcb_in.c:377
#3  0x00007f4b900a5ac3 in _XReply (dpy=0x1cbe570, rep=0x7fffa1623430,
extra=0, 
    discard=1) at xcb_io.c:454
#4  0x00007f4b9008fa9e in XQueryExtension (dpy=0x1cbe570, 
    name=0x7f4b91e8a41b "XINERAMA", major_opcode=0x7fffa162349c, 
    first_event=0x7fffa1623498, first_error=0x7fffa1623494) at
QuExt.c:51
#5  0x00007f4b91e5a460 in init_multihead (screen=<value optimized out>)
    at gdkscreen-x11.c:797
#6  0x00007f4b91e5a5b9 in _gdk_x11_screen_process_monitors_change
(screen=0x4)
    at gdkscreen-x11.c:920
#7  0x00007f4b91e4d215 in gdk_event_translate (display=<value optimized
out>, 
    event=0x1fe8710, xevent=0x7fffa1623680, 
    return_exposes=<value optimized out>) at gdkevents-x11.c:2115
#8  0x00007f4b91e4e687 in _gdk_events_queue (display=0x1ccf000)
    at gdkevents-x11.c:2299
#9  0x00007f4b91e4ea5e in gdk_event_dispatch (source=<value optimized
out>, 
    callback=0x7fffa1623270, user_data=0x7fffa16231f0) at
gdkevents-x11.c:2359
#10 0x00007f4b8df7eccb in g_main_dispatch (context=0x1cd7e00) at
gmain.c:2144
#11 0x00007f4b8df80a8d in g_main_context_iterate (context=0x1cd7e00,
block=1, 
---Type <return> to continue, or q <return> to quit---
    dispatch=1, self=<value optimized out>) at gmain.c:2697
#12 0x00007f4b8df81015 in IA__g_main_loop_run (loop=0x1f590c0) at
gmain.c:2986
#13 0x00000000004283d0 in main (argc=1, argv=0x7fffa1623b98) at
gpm-main.c:253


It seems there is equal chance of interrupting g-p-m during either of
these code paths, either way, gdb stopping g-p-m stops the behaviour
until the process is continued.




More information about the Intel-gfx mailing list