Intel GM45: Loop of continuously triggered output detections

[Jesse Barnes]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center