Intel GM45: Loop of continuously triggered output detections

[Peter Clifton]

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?
-- 
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!)