Created attachment 24144 [details] xorg.0.log System Environment: -------------------------- Host: x-q965 Arch: i386 Platform: G965 OSD: Fedora release 10 (Cambridge) Kernel_version: 2.6.29-rc7-KMS Libdrm: (master)00d8e960ca665b7f0528438331f4d0ae77fbb4cc Mesa: (mesa_7_4_branch)b009a32bf428192fef2dc4787d25f022a472854f Xserver: (server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e Xf86_video_intel: (2.7)e2465249a90b9aefe6d7a96eb56a51fde54698a0 Kernel: (for-airlied)a2e785c32b886dd7f0289d1cf15fc14e9c81bc01 Bug detailed description: -------------------------- the latest update on xf-v-i 2.7 (branch) cause tiled output when start X on all 965 platform, we try to bisect it and find below commit cause this issue: commit e2465249a90b9aefe6d7a96eb56a51fde54698a0 Author: Jesse Barnes <jbarnes@nietzche.localdomain> Date: Thu Mar 19 13:25:29 2009 -0700 Don't install fences if the kernel is managing them If execbuffer is setting up fences, it also means that the kernel is managing them at pin time, so installing one in the 2D driver in that case is an error. The fence should stick around as long as the buffer is pinned (the kernel won't steal these), though it will be freed at leavevt and re-allocated at entervt. On 965+ chips, the pin ioctl will *not* install a fence reg, but that's also ok because all 965+ operations include tiling bits, and sw fallbacks will be protected by prepare/finish access hooks, which will either access the backing store or use the GTT, which will ensure proper fencing at fault time. Fixes #20265. Acked-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 636d252f3b1eac687f7b11952e949c383cb86ed4) Reproduce steps: ---------------------------- 1.xinit&
Created attachment 24145 [details] xorg conf file
it works if set tiling off.
Haien, please try if below patch (it's on master branch but not on 2.7 branch) fixes: New commits: commit 48b91e066878db63a1558e4cd3e6d12ff9c49197 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 20 12:33:22 2009 -0700 Don't manage fences part two Don't try to clear fences that were never installed. Missed this bit in the last fix for #20265. diff --git a/src/i830_memory.c b/src/i830_memory.c index 36dab11..052d906 100644 --- a/src/i830_memory.c +++ b/src/i830_memory.c @@ -270,7 +270,8 @@ i830_unbind_memory(ScrnInfoPtr pScrn, i830_memory *mem) if (mem == NULL || !mem->bound) return TRUE; - if (mem->tiling != TILE_NONE && !pI830->use_drm_mode) + if (mem->tiling != TILE_NONE && !pI830->use_drm_mode && + !pI830->kernel_exec_fencing) i830_clear_tiling(pScrn, mem->fence_nr); #ifdef XF86DRI
(In reply to comment #3) > Haien, please try if below patch (it's on master branch but not on 2.7 branch) > fixes: > > New commits: > commit 48b91e066878db63a1558e4cd3e6d12ff9c49197 > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Fri Mar 20 12:33:22 2009 -0700 > > Don't manage fences part two > > Don't try to clear fences that were never installed. Missed this bit in > the last fix for #20265. > > diff --git a/src/i830_memory.c b/src/i830_memory.c > index 36dab11..052d906 100644 > --- a/src/i830_memory.c > +++ b/src/i830_memory.c > @@ -270,7 +270,8 @@ i830_unbind_memory(ScrnInfoPtr pScrn, i830_memory *mem) > if (mem == NULL || !mem->bound) > return TRUE; > > - if (mem->tiling != TILE_NONE && !pI830->use_drm_mode) > + if (mem->tiling != TILE_NONE && !pI830->use_drm_mode && > + !pI830->kernel_exec_fencing) > i830_clear_tiling(pScrn, mem->fence_nr); > > #ifdef XF86DRI > no,the patch dosen't work for me.
Created attachment 24170 [details] [review] GTT mapping fix I think this is the real fix for this bug, unfortunately it uncovers a bug in the kernel's PAT tracking code which leads to a hang or SIGBUS. Working on fixing that now.
Created attachment 24172 [details] PAT fixes In addition to the 2D driver fix I already posted, you'll need these kernel fixes to make GTT mapping work again.
hi,Jesse your patches don't work for me. Xorg.0.log with your patch is attached.
Created attachment 24175 [details] xorg.0.log with patch
Ah I only fixed the UXA case... lemme update it to include the EXA/DRI1 case.
Created attachment 24204 [details] [review] use GTT maps for front buffer mapping Yet another example of the crazy number of configurations we need to support. This one works for me though, please test (along with rotation etc).
(In reply to comment #10) > Created an attachment (id=24204) [details] > use GTT maps for front buffer mapping > > Yet another example of the crazy number of configurations we need to support. > This one works for me though, please test (along with rotation etc). > yeah, your patch works for me now.
hi,Jesse your patch has fixed the tiled output,but bring in a new regression: the fonts of desktop displays incorrect with your patch.see the attached screenshot.
Created attachment 24219 [details] screenshot with Jesse's patch
btw, the new regression with your patch only happens with uxa.
Created attachment 24242 [details] [review] Use GTT maps Updated patch that unmaps correctly.
Created attachment 24243 [details] [review] libdrm support for unmap You'll need this patch for the unmap support.
(In reply to comment #16) > Created an attachment (id=24243) [details] > libdrm support for unmap > > You'll need this patch for the unmap support. > yes,your patches work for me now,and I don't see any regression yet.
(In reply to comment #16) > Created an attachment (id=24243) [details] > libdrm support for unmap > > You'll need this patch for the unmap support. > Hi Jesse, At first the option Tiling will affect rendercheck(such as dcoords, tscoords, tmcoords failed), it can pass only if I set Tiling off. Now with your these patches, they can pass with tiling on, but it affect composite and cacomposite in rendercheck. It will have some errors and then crash X. intel_bufmgr_gem.c:624: Error mapping buffer 2634 (surface_state): Cannot allocate memory . Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x08127297 in xorg_backtrace () at backtrace.c:42 warning: Source file is more recent than executable. 42 ErrorF("%d: %s\n", i, strings[i]); (gdb) bt #0 0x08127297 in xorg_backtrace () at backtrace.c:42 #1 0x080d1be1 in xf86SigHandler (signo=11) at xf86Events.c:385 #2 <signal handler called> #3 pixman_region32_fini (region=0x1c) at pixman-region.c:328 #4 0xb7ebef9e in pixman_region32_copy_from_region16 (dst=0x1c, src=0xbfdaa18) at pixman-region32.c:67 #5 0xb7ebfc0b in pixman_image_set_clip_region (image=0x0, region=0x1) at pixman-image.c:416 #6 0xb7afc74f in image_from_pict (pict=0xbfd7e10, has_clip=1) at fbpict.c:325 #7 0xb7afcb24 in fbComposite (op=1 '\001', pSrc=0xbfdd5c0, pMask=0xbfe5668, pDst=0xbfd7e10, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=10, height=10) at fbpict.c:181 #8 0xb7ae4046 in ExaCheckComposite (op=1 '\001', pSrc=0xbfdd5c0, pMask=0xbfe5668, pDst=0xbfd7e10, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=10, height=10) at exa_unaccel.c:335 #9 0xb7ae2202 in exaComposite (op=1 '\001', pSrc=0xbfdd5c0, pMask=0xbfe5668, pDst=0xbfd7e10, xSrc=0, ySrc=40, xMask=0, yMask=0, xDst=0, yDst=0, width=10, height=10) at exa_render.c:967 #10 0x08171300 in damageComposite (op=1 '\001', pSrc=0xbfdd5c0, pMask=0xbfe5668, pDst=0xbfd7e10, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, yDst=0, width=10, height=10) at damage.c:643 #11 0x08160f1c in CompositePicture (op=1 '\001', pSrc=0xbfdd5c0, pMask=0xbfe5668, pDst=0xbfd7e10, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=0, ---Type <return> to continue, or q <return> to quit--- yDst=0, width=10, height=10) at picture.c:1675 #12 0x08166bbf in ProcRenderComposite (client=0xbfdbd38) at render.c:720 #13 0x08163a35 in ProcRenderDispatch (client=0xbfabbe0) at render.c:2086 #14 0x0808671f in Dispatch () at dispatch.c:437 #15 0x0806c64d in main (argc=2, argv=0xbfd08a94, envp=0x0) at main.c:397
Created attachment 24280 [details] [review] Use GTT maps Updated 2D patch
Created attachment 24281 [details] [review] libdrm support for GTT maps The last libdrm patch had some bugs. It's probably a good idea to separate the GTT and normal mapping fields, and keep both around in the cache for performance reasons. This version has been more solid for me, but I haven't tested every config yet.
Patches 24280 24281 24172 fix the problem on my GM965 with UXA. Memory usage normal, no fps changes and artifacts on screen disappeared. Good job thanks! :)
Created attachment 24298 [details] [review] Updated 2D patch This one fixes some legacy cases.
*** Bug 20890 has been marked as a duplicate of this bug. ***
Created attachment 24299 [details] [review] Updated updated 2D patch Includes feedback from Eric.
I haven't check logs before.. Looks like PAT fixes needs some improvements. .... X:4871 freeing invalid memtype e11f2000-e11f3000 X:4871 freeing invalid memtype e11f3000-e11f4000 X:4871 freeing invalid memtype e11f4000-e11f5000 X:4871 freeing invalid memtype e11f5000-e11f6000 X:4871 freeing invalid memtype e11f6000-e11f7000 X:4871 freeing invalid memtype e11f7000-e11f8000 X:4871 freeing invalid memtype e11f8000-e11f9000 X:4871 freeing invalid memtype e11f9000-e11fa000 [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0
(In reply to comment #24) > Created an attachment (id=24299) [details] > Updated updated 2D patch > > Includes feedback from Eric. > these patched has fixed the issue of this bug,and rendercheck cases such as composite and cacomposite don't crash X now,but the performance are very slow, each case (e.g composite) takes more than 4 hours.
(In reply to comment #26) > these patched has fixed the issue of this bug,and rendercheck cases such as > composite and cacomposite don't crash X now,but the performance are very slow, > each case (e.g composite) takes more than 4 hours. the rendercheck slowness is an old issue (bug#17762), not a regression caused by this bug or patches here, right?
(In reply to comment #27) > (In reply to comment #26) > > these patched has fixed the issue of this bug,and rendercheck cases such as > > composite and cacomposite don't crash X now,but the performance are very slow, > > each case (e.g composite) takes more than 4 hours. > > the rendercheck slowness is an old issue (bug#17762), not a regression caused > by this bug or patches here, right? > yes,I think so.I get the same result without Jesse's patches.
Fix pushed, thanks for testing. commit 8dabcc40747bfd478f296728741240241698f165 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Mar 30 09:53:40 2009 -0700 Tiling fixes, third set
Unfortunately the fix seems to break the X server on "Intel Corporation 82G35 Express Integrated Graphics Controller rev 3" under kernel 2.6.29 with KMS enabled. At startup time (kdm-4.2.1 on Gentoo) the screen goes blank for around 10 seconds and then shows a nice pattern of pink vertical stripes. The machine stays responsive over remote ssh connections, but is totally unresponsive at the console. Mesa, and libdrm are at their respective git master commits, the X server is at master with the patches from bug 20704 applied. I bisected the latest commits on the master branch of xf86-video-intel and commit 8dabcc40747bfd478f296728741240241698f165 is the first to break the X server for me.
Can you attach your xorg.conf? Does X crash? If so, can you get a backtrace?
Also, are you sure that's the cause? Can you try booting with the "nopat" kernel option to see if it makes the problem go away?
(In reply to comment #31) > Can you attach your xorg.conf? Does X crash? If so, can you get a backtrace? > The X server does not crash, but loops at 100% CPU. Running startx and attaching GDB shows this backtrace: 0x00007f40c53511c0 in fbSolid () from /usr/lib64/xorg/modules/libfb.so (gdb) backtrace #0 0x00007f40c53511c0 in fbSolid () from /usr/lib64/xorg/modules/libfb.so #1 0x00007f40c5349b2c in fbFill () from /usr/lib64/xorg/modules/libfb.so #2 0x00007f40c5349d46 in fbPolyFillRect () from /usr/lib64/xorg/modules/libfb.so #3 0x00007f40c57ca5e1 in uxa_check_poly_fill_rect (pDrawable=0x46d7be0, pGC=0x46d7c50, nrect=1, prect=0x7fffd1cbd290) at uxa-unaccel.c:257 #4 0x00007f40c57c4e16 in uxa_poly_fill_rect (pDrawable=0x46d7be0, pGC=0x46d7c50, nrect=1, prect=0x7fffd1cbd290) at uxa-accel.c:720 #5 0x00000000004bad26 in ?? () #6 0x0000000000478d23 in CreateDefaultStipple () #7 0x0000000000427a65 in ?? () #8 0x00007f40c7102596 in __libc_start_main (main=0x4277f0, argc=9, ubp_av=0x7fffd1cbd3f8, init=0x5661f0 <__libc_csu_init>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffd1cbd3e8) at libc-start.c:226 #9 0x0000000000426fd9 in _start () Here's the xorg.conf file: Section "Monitor" Identifier "SyncMaster 173P" DisplaySize 338 270 # to force 96x96 dpi (from 95xXXX detected) Option "DPMS" "on" EndSection Section "Device" Identifier "G35 Device 0" Driver "intel" Option "AccelMethod" "UXA" Option "XvMC" "true" EndSection Section "Screen" Identifier "G35 Screen 0" Device "G35 Device 0" Monitor "SyncMaster 173P" EndSection Section "ServerFlags" Option "DontZap" "true" Option "AllowEmptyInput" "true" Option "AutoAddDevices" "true" Option "AutoEnableDevices" "true" EndSection Section "ServerLayout" Identifier "Default Layout" Screen "G35 Screen 0" EndSection Section "Extensions" Option "Composite" "Enable" EndSection Section "DRI" Group "video" Mode 0660 EndSection # FontPaths are needed for GoogleEarth?! Section "Files" FontPath "/usr/share/fonts/dejavu" FontPath "/usr/share/fonts/ttf-bitstream-vera" FontPath "/usr/share/fonts/misc/" FontPath "/usr/share/fonts/Type1/" FontPath "/usr/share/fonts/TTF/" FontPath "/usr/share/fonts/75dpi/" FontPath "/usr/share/fonts/100dpi/" FontPath "/usr/share/fonts/corefonts" EndSection and the end of the log file: (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.99.1, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "intel" (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.6.99.1, module version = 2.6.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, IGD_GM, IGD_G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 (II) Primary Device is: PCI 00@00:02:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) intel(0): Creating default Display subsection in Screen section "G35 Screen 0" for depth/fbbpp 24/32 (==) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (**) intel(0): Option "AccelMethod" "UXA" (**) intel(0): Option "XvMC" "true" (II) intel(0): Integrated Graphics Chipset: Intel(R) G35 (--) intel(0): Chipset: "G35" (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (II) intel(0): Resizable framebuffer: available (0 4) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) intel(0): Output VGA1 using monitor section SyncMaster 173P (II) intel(0): EDID vendor "SAM", prod id 211 (II) intel(0): Using EDID range info for horizontal sync (II) intel(0): Using EDID range info for vertical refresh (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) intel(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) intel(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) intel(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) intel(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) intel(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) intel(0): Output VGA1 connected (II) intel(0): Using exact sizes for initial modes (II) intel(0): Output VGA1 using initial mode 1280x1024 (II) intel(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. (==) intel(0): video overlay key set to 0x101fe (**) intel(0): Display dimensions: (338, 270) mm (**) intel(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/lib64/xorg/modules/libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.99.1, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) intel(0): [DRI2] Setup complete (**) intel(0): Framebuffer compression disabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: -1 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) UXA(0): Driver registered support for the following operations: (II) solid (II) copy (II) composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0xffffffffffffffff: DRI memory manager (0 kB) (II) intel(0): 0x00000000: end of aperture (II) intel(0): BO memory allocation layout: (II) intel(0): 0x00000000: start of memory manager (II) intel(0): 0x014ff000-0x019fefff: front buffer (5120 kB) (II) intel(0): 0x014ef000-0x014f8fff: HW cursors (40 kB) (II) intel(0): 0x00000000: end of memory manager (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (**) intel(0): DPMS enabled (==) intel(0): Intel XvMC decoder disabled (II) intel(0): Set up textured video (II) intel(0): direct rendering: DRI2 Enabled (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: enabled GLX_MESA_copy_sub_buffer (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects (II) AIGLX: Loaded and initialized /usr/lib64/dri/i965_dri.so (II) GLX: Initialized DRI2 GL provider for screen 0 (II) intel(0): Setting screen physical size to 338 x 270 At this point the server seems to hang. Prior to commit 8dabcc40 the output would be exactly the same up to this point and then continue with the hal configuration of touchpad and keyboard.
(In reply to comment #33) > (In reply to comment #31) > > Can you attach your xorg.conf? Does X crash? If so, can you get a backtrace? > > > > The X server does not crash, but loops at 100% CPU. Running startx and > attaching GDB shows this backtrace: > > 0x00007f40c53511c0 in fbSolid () from /usr/lib64/xorg/modules/libfb.so > (gdb) backtrace > #0 0x00007f40c53511c0 in fbSolid () from /usr/lib64/xorg/modules/libfb.so > #1 0x00007f40c5349b2c in fbFill () from /usr/lib64/xorg/modules/libfb.so > #2 0x00007f40c5349d46 in fbPolyFillRect () > from /usr/lib64/xorg/modules/libfb.so > #3 0x00007f40c57ca5e1 in uxa_check_poly_fill_rect (pDrawable=0x46d7be0, > pGC=0x46d7c50, nrect=1, prect=0x7fffd1cbd290) at uxa-unaccel.c:257 > #4 0x00007f40c57c4e16 in uxa_poly_fill_rect (pDrawable=0x46d7be0, > pGC=0x46d7c50, nrect=1, prect=0x7fffd1cbd290) at uxa-accel.c:720 > #5 0x00000000004bad26 in ?? () > #6 0x0000000000478d23 in CreateDefaultStipple () > #7 0x0000000000427a65 in ?? () > #8 0x00007f40c7102596 in __libc_start_main (main=0x4277f0, argc=9, > ubp_av=0x7fffd1cbd3f8, init=0x5661f0 <__libc_csu_init>, > fini=<value optimized out>, rtld_fini=<value optimized out>, > stack_end=0x7fffd1cbd3e8) at libc-start.c:226 > #9 0x0000000000426fd9 in _start () Ah this looks like the PAT bug then, can you try booting with 'nopat' to see if it goes away? What's happening is that the i915 driver is continually trying to fault in a page for the fb routines to access, but the kernel is returning EINVAL (a new and fairly useless error code in this case), which we interpret as success. But in fact the new PTE *hasn't* been installed, so we just fault again on the same address and hang. The fixes for this are upstream already in Linus's tree, but haven't made their way into the drm-intel or stable kernel release yet (2.6.29.1 should contain the fix though).
nopat fixes the issue. Thanks for pointing out this workaround. Can you point me to the patch that needs to be applied to the kernel, please?
From Linus's tree: commit 4bb9c5c02153dfc89a6c73a6f32091413805ad7d Author: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> Date: Thu Mar 12 17:45:27 2009 -0700 VM, x86, PAT: Change is_linear_pfn_mapping to not use vm_pgoff I think that's the main one... There's also a thread on lkml, subject "2.6.29 git master and PAT problems" if you want to jump in.
This commit bring back 3D performance when running 2.6.29 with KMS enabled on my G33. However, when I disable KMS and use EXA instead of UXA, 2D performance is horrible. I did a git bisect on the 2.7 branch and found this commit. The logs don't show any differences between having this commit enabled or not.
verified against: Libdrm: (master)8b8e20e0f9900fae23baee55a91533a739c1a3ec Mesa: (master)10c4a10b979bddd099287dec5b69243c2ade8ade Xserver: (master)f3c61377d0fb1f09a18833995556fc9ffd11e097 Xf86_video_intel: (master)52367847087206b92f18c40d356d36ab9ee89d39 Kernel: (for-linus)79f11c19a396e8cea7dad322dcfb46c0a8517fe6
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.