Xrandr loop with gnome-settings-daemon [WAS: Re: Intel GM45: Loop of continuously triggered output detections]

Wed Jan 14 02:14:59 PST 2009

On Tue, 2009-01-13 at 18:32 +0000, Peter Clifton wrote:
> On Tue, 2009-01-13 at 09:08 -0800, Jesse Barnes wrote:
> > On Tuesday, January 13, 2009 6:58 am Peter Clifton wrote:
> > > On Tue, 2009-01-13 at 17:26 +0800, Jin, Gordon wrote:
> > > > Peter Clifton wrote on Tuesday, January 13, 2009 11:45 AM:
> > > > > On Tue, 2009-01-13 at 01:55 +0000, Peter Clifton wrote:
> > > > >> Testing git HEAD intel drivers, also recent Xorg:
> > > > >>
> > > > >>
> > > > >> After the problem with miss-detected TV-out, I killed Xorg with a
> > > > >> Ctrl +Alt+Backspace (I've got zapping re-enabled in my xorg.conf),
> > > > >> and the outputs detected properly, with no TV output detected as
> > > > >> being connected.
> > > > >>
> > > > >> The performance was very slow, however, and with the characteristic
> > > > >> "jiggle" / jittering of the mouse cursor position which I've
> > > >
> > > > noticed
> > > >
> > > > >> on both my Intel based machines during output detection.
> > > > >>
> > > > >> Trying xrandr, adjusting brightness, had no effect. A couple of VT
> > > > >> switches to VT1 and back to Xorg finally stopped the detection
> > > >
> > > > loop,
> > > >
> > > > >> although during that process, one of the the switches to VT1 left
> > > >
> > > > me
> > > >
> > > > >> with a corrupted console. (Possibly scanning out from the wrong
> > > >
> > > > part
> > > >
> > > > >> of the frame-buffer, perhaps with the wrong sync settings?).
> > > > >>
> > > > >> I've attached the log. It does show a page-table problem with the
> > > > >> last VT switch.
> > > > >
> > > > > I managed to re-trigger this bug by pulling the laptop's AC power
> > > > > adaptor out, and plugging it back in again. I suspect either an ACPI
> > > > > event, or something inside HP's SMM BIOS code triggered it. My old
> > > >
> > > > HP
> > > >
> > > > > nc 6320 didn't properly respect _DOS bit 4, so would always fiddle
> > > > > with the graphics hardware when you plugged / unplugged the AC
> > > > > adaptor.
> > > > >
> > > > > I've not dug deeply into this one, so I'm not quite blaming the BIOS
> > > > > yet, however it is looking somewhat guilty.
> > > >
> > > > This looks similar to
> > > > http://bugs.freedesktop.org/show_bug.cgi?id=19431, interesting bug.
> > >
> > > It only bears very supercficial similarities as far as I can see.
> > >
> > > Yes, I had a problem with intermittent TV out detection, but that
> > > doesn't appear to be dependent on battery state.
> > >
> > > My problem is that "something" (often triggered by an AC state change,
> > > but sometimes just when I boot up) is triggering a storm of probes to
> > > detect outputs. I did wonder if this might be due to a faulty detection
> > > routine trying to spot that I inserted a cable in one of the outputs,
> > > however this backtrace I grabbed whilst the problem was occuring
> > > suggests that it is being dispatched through the X server:
> > >
> > > #0  0xb809e430 in __kernel_vsyscall ()
> > > #1  0xb7ce7700 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6
> > > #2  0xb7d24ffc in usleep () from /lib/tls/i686/cmov/libc.so.6
> > > #3  0xb7ab826e in i830WaitForVblank (pScreen=0xa197040) at
> > > ../../src/i830_display.c:379 #4  0xb7abaf80 in i830_crtc_mode_set
> > > (crtc=0xa199b80, mode=0xbfdb9ea0, adjusted_mode=0xa4d70e8, x=0, y=0) at
> > > ../../src/i830_display.c:1511 #5  0x080ed08d in xf86CrtcSetModeTransform
> > > (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=1, transform=0x0, x=0, y=0) at
> > > ../../../../hw/xfree86/modes/xf86Crtc.c:366
> > > #6  0x080ed6d6 in xf86CrtcSetMode (crtc=0xa199b80, mode=0xbfdb9ea0,
> > > rotation=8180, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:413 #7 
> > > 0xb7ab956d in i830GetLoadDetectPipe (output=0xa19b618, mode=0xbfdb9ea0,
> > > dpms_mode=0xbfdb9f78) at ../../src/i830_display.c:1811 #8  0xb7ad746d in
> > > i830_tv_detect (output=0xa19b618) at ../../src/i830_tv.c:1376 #9 
> > > 0x080eda90 in xf86ProbeOutputModes (scrn=0xa197040, maxX=4096, maxY=4096)
> > > at ../../../../hw/xfree86/modes/xf86Crtc.c:1500 #10 0x080f56c0 in
> > > xf86RandR12GetInfo12 (pScreen=0xa19c460, rotations=0xbfdba16a) at
> > > ../../../../hw/xfree86/modes/xf86RandR12.c:1255 #11 0x08162e89 in RRGetInfo
> > > (pScreen=0xa19c460) at ../../randr/rrinfo.c:196 #12 0x08167084 in
> > > ProcRRGetScreenSizeRange (client=0xa3d2208) at ../../randr/rrscreen.c:227
> > > #13 0x0815f305 in ProcRRDispatch (client=0x0) at ../../randr/randr.c:473
> > > #14 0x0808cdbf in Dispatch () at ../../dix/dispatch.c:437
> > > #15 0x08071aad in main (argc=10, argv=0xbfdba324, envp=Cannot access memory
> > > at address 0x8 ) at ../../dix/main.c:383
> > >
> > >
> > > Does anyone know if there is an easy way to ascertain from a backtrace,
> > > which client caused a particular dispatch? (Perhaps chasing back
> > > through /proc/ or netstat to find out more info on the actual process
> > > involved?
> > 
> > Well, the randr functions are in the backtrace, so it's possible some 
> > application is triggering the re-probe.  That doesn't mean your BIOS isn't 
> > causing trouble though: it could be sending ACPI events that are getting 
> > picked up by some app which is then doing a re-probe.  You should be able to 
> > check out your ACPI daemon log or use acpi_listen to see if that's happening.
> 
> Turns out that the problem probes are sent by gnome-settings-daemon.
> I've yet to figure out why they are triggered.
> 
> acpi_listen didn't show anything untoward (other than that my HP 6730
> laptop doesn't bother emitting LID events when I open / close the lid).
> 
> Killing gnome-settings daemon and then restarting it from within my
> session seems to have calmed it down somewhat. I can't persuade the loop
> to re-trigger again this session since I did that.

Ok, seems that every time I change brightness with a hotkey, I get an
Xrandr notification, which cause gnome-settings-daemon to round-trip,
requesting XRRGetScreenSizeRange, which in turn causes a monitor
reprobe.

When I change brightness, I only get a single output probe, (On the
intel graphics driver this causes the hardware drawn mouse-pointer to
jump if you're moving the mouse, so you can count them!).

In the bug I'm describing above - often triggered by switching to / from
AC on this laptop, seemingly whatever is probed triggers a further
Xrandr notification, which starts the whole process running into a big
long loop.

What are the correct locking / notification blocking semantics which
should avoid this bug?

Should gnome-settings-daemon be avoiding retaliating to a notification
by requesting XRRGetScreenSizeRange, or should XRRGetScreenSizeRange
avoid calling a procedure which will emit another notification?

Here follows some backtraces, and what may be pertinent extra debug
information gleaned from GDB. This was tested using a brightness hotkey
(which are mapped through keyboard scancodes on this laptop, not ACPI
notifications).

**** Change brightness (for example) *********

Breakpoint 1, XRRGetScreenSizeRange (dpy=0x92ade28, window=121, 
    minWidth=0x945c1f0, minHeight=0x945c1f8, maxWidth=0x945c1f4, 
    maxHeight=0x945c1fc) at ../../src/XrrScreen.c:217
217	../../src/XrrScreen.c: No such file or directory.
	in ../../src/XrrScreen.c
(gdb) bt
#0  XRRGetScreenSizeRange (dpy=0x92ade28, window=121, minWidth=0x945c1f0, 
    minHeight=0x945c1f8, maxWidth=0x945c1f4, maxHeight=0x945c1fc) at ../../src/XrrScreen.c:217
#1  0xb71552e7 in screen_info_new (screen=<value optimized out>, error=0x0) at gnome-rr.c:339
#2  0xb7155fab in screen_update (screen=0x92e7eb8, force_callback=1, error=0x0) at gnome-rr.c:480
#3  0xb71560d4 in screen_on_event (xevent=0xbfe76fd8, event=0x92b8780, data=0x92e7eb8) at gnome-rr.c:518
#4  0xb7c53749 in gdk_event_translate (display=0x92b50b0, event=0x92b8780, xevent=0xbfe76fd8, return_exposes=0) at /build/buildd/gtk+2.0-2.14.5/gdk/x11/gdkevents-x11.c:349
#5  0xb7c55193 in _gdk_events_queue (display=0x92b50b0) at /build/buildd/gtk+2.0-2.14.5/gdk/x11/gdkevents-x11.c:2299
#6  0xb7c555bf in gdk_event_dispatch (source=0x92bc230, callback=0, user_data=0x0) at /build/buildd/gtk+2.0-2.14.5/gdk/x11/gdkevents-x11.c:2359
#7  0xb7847b18 in IA__g_main_context_dispatch (context=0x92bc278) at /build/buildd/glib2.0-2.19.4/glib/gmain.c:1814
#8  0xb784b1c3 in g_main_context_iterate (context=0x92bc278, block=1, dispatch=1, self=0x92a9f50) at /build/buildd/glib2.0-2.19.4/glib/gmain.c:2448
#9  0xb784b6e2 in IA__g_main_loop_run (loop=0x93f0aa0) at /build/buildd/glib2.0-2.19.4/glib/gmain.c:2656
---Type <return> to continue, or q <return> to quit---q
Quit

(gdb) frame 3
#3  0xb71560d4 in screen_on_event (xevent=0xbfe76fd8, event=0x92b8780, 
    data=0x92e7eb8) at gnome-rr.c:518
518	gnome-rr.c: No such file or directory.
	in gnome-rr.c
(gdb) print *((XRRNotifyEvent *)xevent)
$17 = {type = 101, serial = 39875, send_event = 0, display = 0x92ade28, window = 121, subtype = 2}

(gdb) c
Continuing.

Breakpoint 1, XRRGetScreenSizeRange (dpy=0x92ade28, window=121, 
    minWidth=0x9529ca0, minHeight=0x9529ca8, maxWidth=0x9529ca4, 
    maxHeight=0x9529cac) at ../../src/XrrScreen.c:217
217	../../src/XrrScreen.c: No such file or directory.
	in ../../src/XrrScreen.c
(gdb) frame 3
#3  0xb71560d4 in screen_on_event (xevent=0xbfe76fd8, event=0x92b8780, 
    data=0x92e7eb8) at gnome-rr.c:518
518	gnome-rr.c: No such file or directory.
	in gnome-rr.c
(gdb) print *((XRRNotifyEvent *)xevent)
$18 = {type = 101, serial = 39875, send_event = 0, display = 0x92ade28, window = 121, subtype = 2}

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)