Bug 20803

Summary: [regression i965]tiled output when start X
Product: xorg Reporter: liuhaien <haien.liu>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: VERIFIED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: highest CC: arekm, eric, jan, Magnus.Kessler, remi
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 20276    
Attachments:
Description Flags
xorg.0.log
none
xorg conf file
none
GTT mapping fix
none
PAT fixes
none
xorg.0.log with patch
none
use GTT maps for front buffer mapping
none
screenshot with Jesse's patch
none
Use GTT maps
none
libdrm support for unmap
none
Use GTT maps
none
libdrm support for GTT maps
none
Updated 2D patch
none
Updated updated 2D patch none

Description liuhaien 2009-03-22 22:49:55 UTC
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&
Comment 1 liuhaien 2009-03-22 22:50:22 UTC
Created attachment 24145 [details]
xorg conf file
Comment 2 liuhaien 2009-03-22 22:51:00 UTC
it works if set tiling off.
Comment 3 Gordon Jin 2009-03-23 00:10:36 UTC
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
Comment 4 liuhaien 2009-03-23 00:45:50 UTC
(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.
Comment 5 Jesse Barnes 2009-03-23 11:58:29 UTC
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.
Comment 6 Jesse Barnes 2009-03-23 15:28:01 UTC
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.
Comment 7 liuhaien 2009-03-23 19:13:23 UTC
hi,Jesse
your patches don't work for me. Xorg.0.log with your patch is attached.
Comment 8 liuhaien 2009-03-23 19:14:18 UTC
Created attachment 24175 [details]
xorg.0.log with patch
Comment 9 Jesse Barnes 2009-03-24 09:39:30 UTC
Ah I only fixed the UXA case... lemme update it to include the EXA/DRI1 case.
Comment 10 Jesse Barnes 2009-03-24 09:54:26 UTC
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).
Comment 11 liuhaien 2009-03-24 18:42:56 UTC
(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.
Comment 12 liuhaien 2009-03-24 19:20:32 UTC
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.
Comment 13 liuhaien 2009-03-24 19:21:31 UTC
Created attachment 24219 [details]
screenshot with Jesse's patch
Comment 14 liuhaien 2009-03-25 01:57:08 UTC
btw, the new regression with your patch only happens with uxa.
Comment 15 Jesse Barnes 2009-03-25 13:50:04 UTC
Created attachment 24242 [details] [review]
Use GTT maps

Updated patch that unmaps correctly.
Comment 16 Jesse Barnes 2009-03-25 13:50:36 UTC
Created attachment 24243 [details] [review]
libdrm support for unmap

You'll need this patch for the unmap support.
Comment 17 liuhaien 2009-03-25 18:57:09 UTC
(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.
Comment 18 zhao jian 2009-03-26 01:30:58 UTC
(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

Comment 19 Jesse Barnes 2009-03-26 12:04:04 UTC
Created attachment 24280 [details] [review]
Use GTT maps

Updated 2D patch
Comment 20 Jesse Barnes 2009-03-26 12:05:08 UTC
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.
Comment 21 Mateusz Kaduk 2009-03-26 17:30:20 UTC
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! :)
Comment 22 Jesse Barnes 2009-03-26 18:15:08 UTC
Created attachment 24298 [details] [review]
Updated 2D patch

This one fixes some legacy cases.
Comment 23 Jesse Barnes 2009-03-26 19:04:49 UTC
*** Bug 20890 has been marked as a duplicate of this bug. ***
Comment 24 Jesse Barnes 2009-03-26 19:10:42 UTC
Created attachment 24299 [details] [review]
Updated updated 2D patch

Includes feedback from Eric.
Comment 25 Mateusz Kaduk 2009-03-26 23:45:18 UTC
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

Comment 26 liuhaien 2009-03-27 02:30:16 UTC
(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.
Comment 27 Gordon Jin 2009-03-27 20:12:44 UTC
(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? 

Comment 28 liuhaien 2009-03-29 18:58:06 UTC
(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. 
Comment 29 Jesse Barnes 2009-03-30 10:00:35 UTC
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
Comment 30 Magnus Kessler 2009-03-31 09:25:51 UTC
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.
Comment 31 Jesse Barnes 2009-03-31 09:51:08 UTC
Can you attach your xorg.conf?  Does X crash?  If so, can you get a backtrace?
Comment 32 Jesse Barnes 2009-03-31 11:57:05 UTC
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?
Comment 33 Magnus Kessler 2009-03-31 12:09:31 UTC
(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.

Comment 34 Jesse Barnes 2009-03-31 12:17:46 UTC
(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).
Comment 35 Magnus Kessler 2009-03-31 12:26:05 UTC
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?
Comment 36 Jesse Barnes 2009-03-31 12:35:03 UTC
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.
Comment 37 Jan de Groot 2009-04-02 15:42:42 UTC
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.
Comment 38 liuhaien 2009-05-14 02:18:32 UTC
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.