On Wed, 2009-01-14 at 10:14 +0000, Peter Clifton wrote: > 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.
Also, it might be useful to note, that I only tend to get the corrupted console symptom when doing a VT switch whilst this Xrandr probe loop is running. Once I've killed gnome-settings-daemon, I can VT switch (usually giving a corrupt console), at which point, any backlog of events appears to be dropped. Further VT7 / VT1 switches don't appear to result in corruption. -- 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!) _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
