On Sat, 2008-11-08 at 18:49 +0000, Steven J Newbury wrote: > On Sat, 2008-11-08 at 12:34 +0000, Steven J Newbury wrote: > > 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. > > This is clearly an incarnation of the known, very slow, > XRRGetScreenResources()/GTK interaction. I suppose I just have to wait > for this to be resolved one way or another... > g-p-m from the GNOME subversion trunk fixes this by caching the output of XRRGetScreenResources(). It's at least the latest release (2.24.1) which shows this behaviour. Time for a new release of g-p-m I'd say, or at the very least a backported patch to any distro that uses 2.24.1.
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel