Reported by Kim Hansen on the Debian BTS yesterday. Applies to intel driver 2.2.0.90. This may be similar to bug#13376 but the symptoms are different (crash instead of lockup). He says: "When I configure X for a dual screen setup with a large Virtual display it cashes unless I also turn of acceleration using the NoAccel option. The crash is immediate for me, it happens when gdm starts X." His config and log are available at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=465421 He sent the following backtrace of the crash: The hardware is a Toshiba M400. #0 0xffffe410 in __kernel_vsyscall () No symbol table info available. #1 0xb7d48f15 in raise () from /lib/i686/cmov/libc.so.6 No symbol table info available. #2 0xb7d4a891 in abort () from /lib/i686/cmov/libc.so.6 No symbol table info available. #3 0x080a87f7 in ddxGiveUp () at ../../../../hw/xfree86/common/xf86Init.c:1073 i = <value optimized out> #4 0x081bae98 in AbortServer () at ../../os/log.c:406 No locals. #5 0x081bb416 in FatalError (f=0x81c5e9c "Caught signal %d. Server aborting\n") at ../../os/log.c:552 args = 0xbf897594 "\v" beenhere = 1 #6 0x080c67cd in xf86SigHandler (signo=11) at ../../../../hw/xfree86/common/xf86Events.c:766 No locals. #7 <signal handler called> No symbol table info available. #8 0xb7b41923 in I830WaitLpRing (pScrn=0x8217e88, n=8, timeout_millis=2000) at ../../src/i830_accel.c:120 pI830 = (I830Ptr) 0x8219828 ring = (I830RingBuffer *) 0x8229178 iters = 0 start = 0 last_head = 0 #9 0xb7b41a50 in I830EmitFlush (pScrn=0x0) at ../../src/i830_accel.c:217 outring = <value optimized out> pI830 = (I830Ptr) 0x8219828 __FUNCTION__ = "I830EmitFlush" #10 0xb7b6c4b8 in I830DRISwapContext (pScreen=0x8227748, syncType=<value optimized out>, oldContextType=0, oldContext=0x0, newContextType=1, newContext=0x8228ff8) at ../../src/i830_dri.c:1153 pPix = <value optimized out> pScrn = (ScrnInfoPtr) 0x8217e88 pI830 = (I830Ptr) 0x8219828 __func__ = "I830DRISwapContext" #11 0xb7f94f57 in DRIDoBlockHandler (screenNum=0, blockData=0x0, pTimeout=0xbf897cd8, pReadmask=0x8206720) at ../../../../hw/xfree86/dri/dri.c:1709 pScreen = (ScreenPtr) 0x8227748 pDRIPriv = (DRIScreenPrivPtr) 0x8227ab8 #12 0xb7f93dd2 in DRIBlockHandler (blockData=0x0, pTimeout=0xbf897cd8, pReadmask=0x8206720) at ../../../../hw/xfree86/dri/dri.c:1676 pScreen = <value optimized out> i = 0 #13 0x08090e14 in BlockHandler (pTimeout=0xbf897cd8, pReadmask=0x8206720) at ../../dix/dixutils.c:445 i = 2 j = 0 #14 0x081ada38 in WaitForSomething (pClientsReady=0xbf897d10) at ../../os/WaitFor.c:222 i = <value optimized out> waittime = {tv_sec = 0, tv_usec = 0} wt = (struct timeval *) 0xbf897cd0 timeout = <value optimized out> clientsReadable = {fds_bits = {0 <repeats 32 times>}} clientsWritable = {fds_bits = {138114024, 136760472, 7, 7, 1, -1081508880, 0, 138114264, -1081508544, 226653584, 35, -1210966852, -1210971360, -1214154877, -1214154876, -1214154873, 0, 0, 1, 1142, 136467808, -1209374736, -1214154877, -1210930548, -1214160256, 1, -1208197132, 136476120, -1081508556, -1081508528, -1208275094, -1214160256}} curclient = <value optimized out> selecterr = 1 nready = <value optimized out> devicesReadable = {fds_bits = {138138760, 138114264, -1081508920, -1214081457, 138114024, 136760472, 138138760, 1, 0, 1, 1, 14, 14, 1, 138114264, 0, 154, 0, 138138760, 136760572, 1, 1, 14, 14, 0, 1, 7, 136148076, 17, -1081508884, -1081507848, 135433476}} now = 48517870 someReady = 0 #15 0x0808cfb2 in Dispatch () at ../../dix/dispatch.c:425 result = <value optimized out> client = (ClientPtr) 0x81e1300 nready = 16711680 start_tick = 65280 #16 0x0807470b in main (argc=1, argv=0xbf898234, envp=Cannot access memory at address 0x8 ) at ../../dix/main.c:452 pScreen = <value optimized out> i = 1 error = 136148076 xauthfile = <value optimized out> alwaysCheckForInput = {0, 1}
Does this problem happen if using XAA? Is this a regression? e.g. Does 2.2.0 work for the user? If so, is it possible to find the regression commit by git-bisect? (Assigning to Jesse, since this is a bit similar to #13376)
(In reply to comment #1) > Does this problem happen if using XAA? Yes > Is this a regression? e.g. Does 2.2.0 work for the user? If so, is it possible > to find the regression commit by git-bisect? I don't think it is a regression, I get the same crashes when using the Debian packages xserver-xorg-video-intel version 2:2.1.99-1 and 2:2.2.0-1.
This should be fixed in current master, pls retest.
*** This bug has been marked as a duplicate of bug 13376 ***
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.