Created attachment 69587 [details] Xorg log On Gentoo when starting X with built-in laptop display LVDS1 and having display attached VGA1 causes X to crash quite quickly while enlightenment is initializing (compositing is active). Package versions: xorg-server-12.2 libdrm-2.4.39 xf86-video-indel-2.20.8 linux-3.6.0 GPU: 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) Laptop: Acer TravelMate 66x
Can you please first update to 2.20.12 (preferably to git as that contains a fix for a crash with alphamaps)? And if it still crashes, please translate the stacktrace using 'addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so 0xblah...'.
Rebuilt with explicit -ggdb in CFLAGS, addr2line -e /usr/lib/debug/usr/lib/xorg/modules/drivers/intel_drv.so.debug 0x46532 /var/tmp/portage/x11-drivers/xf86-video-intel-2.20.8/work/xf86-video-intel-2.20.8/src/sna/sna_damage.c:1466 Annotated stacktrace: [ 13311.280] Backtrace: [ 13311.280] 0: /usr/bin/Xorg (xorg_backtrace+0x50) [0x81cfe90] [ 13311.280] 1: /usr/bin/Xorg (0x8048000+0x18b9ff) [0x81d39ff] [ 13311.280] 2: linux-gate.so.1 (__kernel_rt_sigreturn+0x0) [0xb771140c] [ 13311.280] 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb710c000+0x46532) 3: src/sna/sna_damage.c:1466 [ 13311.280] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb710c000+0x5c3c0) 4: src/sna/sna_render.c:1921 [ 13311.281] 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb710c000+0x7ad4c) 5: src/sna/gen2_render.c:1106 [ 13311.281] 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb710c000+0x43913) 6: src/sna/sna_composite.c:565 [ 13311.281] 7: /usr/bin/Xorg (0x8048000+0x108c42) [0x8150c42] [ 13311.281] 8: /usr/bin/Xorg (CompositePicture+0x2b4) [0x8142f14] [ 13311.281] 9: /usr/bin/Xorg (0x8048000+0xfdf59) [0x8145f59] [ 13311.281] 10: /usr/bin/Xorg (0x8048000+0xfb6f3) [0x81436f3] [ 13311.281] 11: /usr/bin/Xorg (0x8048000+0x3165d) [0x807965d] [ 13311.281] 12: /usr/bin/Xorg (0x8048000+0x1ecdd) [0x8066cdd] [ 13311.281] 13: /lib/libc.so.6 (__libc_start_main+0xe4) [0xb73d45a4] [ 13311.281] 14: /usr/bin/Xorg (0x8048000+0x1e8a1) [0x80668a1] [ 13311.281] [ 13311.281] Segmentation fault at address 0x1c09d356 Now going to test more recent releases (2.20.12 and GIT)
Created attachment 69668 [details] Trace for xf86-video-intel-2.20.12 Seems to happen less regularly with 2.20.12 that it does with 2.20.8. Now going to retry with -git.
-git fails to compile here: src/i810_driver.c:569:23: error: 'struct _vgaHWRec' has no member named 'PIOOffset' Does -git need a specific xorg-server version newer than 1.12.2 (struct _vgaHWRec being declared in a xorg-server header)?
(In reply to comment #4) > -git fails to compile here: > src/i810_driver.c:569:23: error: 'struct _vgaHWRec' has no member named > 'PIOOffset' $ git grep PIOOffset $ I don't think your -git is uptodate. :)
Anyway, my first thoughts are that we have some memory corruption that is peculiar to i8xx. It will be interesting first to get -intel.git up and running, and then start probing.
Created attachment 69838 [details] Trace for xf86-video-intel-git 93d8dddbb9 Ok, I got -git running (don't know what went wrong with -9999 ebuild the other day). Still same looking crash. Just having a window on LVDS while enlightenment shelves and a few other small windows are on VGA seems sufficient to crash things when sole window (covering most of LVDS space) on LVDS refreshes (claws-mail starting). Don't know if somehow related, when disabling VGA via xrandr, during modeset flicker LVDS displays 2/3 with "old content" and "1/3" uniform white until things get recomposed. Wasn't there a magic 2048 number for i855 or i8xx and older?
(In reply to comment #7) > Don't know if somehow related, when disabling VGA via xrandr, during modeset > flicker LVDS displays 2/3 with "old content" and "1/3" uniform white until > things get recomposed. Wasn't there a magic 2048 number for i855 or i8xx and > older? Yes, each pipe (crtc) can only handle up to 2048x2048 pixels. The ddx splits the framebuffer to fit into each pipe and fixes up the rendering accordingly. That you see flicker during modeset is a kernel bug... For now, let's fix the crash.
The stacktrace implies it dies within the error path of gen2_composite(), so probably just some corruption/incorrect initialisation (I can hope). Can you please pull commit f5d79b202dd448e61ab6ffce26fe9cbf9051d770 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Nov 10 10:30:04 2012 +0000 sna/gen2: Add a modicum of fallback DBG References: https://bugs.freedesktop.org/show_bug.cgi?id=56785 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> and run with --enable-debug=full (and attach the resulting Xorg.log)? Running under valgrind would definitely be very useful as well.
I've finally setup LVDS with 1024x768 and hooked up a VGA with 1920x1080 to the right-of LVDS. Launched e17 with firefox on the LVDS and chromium on the VGA... So far so good. (Actually quite amazing considering ;-)
Created attachment 69869 [details] Xorg.log for GIT at f5d79b202dd with --enable-debug=full
Created attachment 69870 [details] Valgrind output corresponding to attachment #69869 [details]
Gotcha! commit 94dd0b9ee9f55e7c09b8c0ee18939fa69ce66da2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Nov 10 16:52:09 2012 +0000 sna/gen2: Fix use of uninitialised redirection ==29553== Invalid read of size 4 ==29553== at 0x4980E1B: _list_del (intel_list.h:218) ==29553== by 0x4980EB3: list_del (intel_list.h:240) ==29553== by 0x4981F53: free_list (sna_damage.c:403) ==29553== by 0x4985139: __sna_damage_destroy (sna_damage.c:1467) ==29553== by 0x49A527E: sna_render_composite_redirect_done (sna_render.c:1921) ==29553== by 0x49C6904: gen2_render_composite_done (gen2_render.c:1136) ==29553== by 0x497F917: sna_composite (sna_composite.c:567) ==29553== by 0x8150C41: ??? (in /usr/bin/Xorg) ==29553== by 0x8142F13: CompositePicture (in /usr/bin/Xorg) ==29553== by 0x8145F58: ??? (in /usr/bin/Xorg) ==29553== by 0x81436F2: ??? (in /usr/bin/Xorg) ==29553== by 0x807965C: ??? (in /usr/bin/Xorg) ==29553== Address 0x9407e188 is not stack'd, malloc'd or (recently) free'd Reported-by: bonbons67@internet.lu Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56785 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 69896 [details] Valgrind output for GIT at 94dd0b9ee9f55e7c09b8c0ee18939fa69ce66da2 Still crashing, but not as easyly anymore it seems. Valgrind trace looks very similary, but this time there are two extra drv_intel.so glyph-functions inserted between X and previous path.
Created attachment 69897 [details] Xorg.log with --enable-debug=full corresponding to attachment #69896 [details] Dropped most debug log of drv_intel.so, except last ~10s and first few seconds (otherwise 100MB of raw log!)
Next: commit b16219a19f48b52dda91f26fcbbbbeda056589ab Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 11 11:05:35 2012 +0000 sna: Filter out the full-damage marker when undoing redirection ==25902== Invalid read of size 4 ==25902== at 0x4980E13: _list_del (intel_list.h:218) ==25902== by 0x4980EAB: list_del (intel_list.h:240) ==25902== by 0x4981F4B: free_list (sna_damage.c:403) ==25902== by 0x4985131: __sna_damage_destroy (sna_damage.c:1467) ==25902== by 0x49A5276: sna_render_composite_redirect_done (sna_render.c: ==25902== by 0x49C68FC: gen2_render_composite_done (gen2_render.c:1136) ==25902== by 0x497F90F: sna_composite (sna_composite.c:567) ==25902== by 0x4994725: glyphs_via_mask (sna_glyphs.c:1139) ==25902== by 0x4995FB7: sna_glyphs (sna_glyphs.c:1688) ==25902== by 0x8150EB4: ??? (in /usr/bin/Xorg) ==25902== by 0x813CA38: CompositeGlyphs (in /usr/bin/Xorg) ==25902== by 0x8146DE1: ??? (in /usr/bin/Xorg) ==25902== Address 0x7c079ac2 is not stack'd, malloc'd or (recently) free'd Reported-by: bonbons67@internet.lu Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56785
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.