Bug 18974

Summary: [8xx] Fatal server error: Couldn't bind memory for BO front buffer in 2.5.1 driver
Product: xorg Reporter: Bryce Harrington <bryce>
Component: Driver/intelAssignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: medium CC: acevery, aguertin+freedesktop, arthurspitzer, butcheeyboy, daryl, dirk.gerrits, karsten, lefty, marques, maxi, maxi, mrmazda, n-roeser, online, opensource, pachoramos1, remi, shirishag75, shrek, yan.i.li, zdenek.kabelac, zeekec
Version: unspecifiedKeywords: NEEDINFO
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg.0.log
none
intel driver failing to load on :1 while :0 is occupied with intelfb/fbdev driver
none
Xorg.0.log
none
Failure log
none
"*ERROR* GTT full, but LRU list empty" in kernel.log none

Description Bryce Harrington 2008-12-09 01:00:08 UTC
Created attachment 20941 [details]
Xorg.0.log

Forwarding this bug report from a Ubuntu reporter:
https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/304871
Also seen on Fedora:
http://webui.sourcelabs.com/fedora/issues/461829

[Problem]
X hangs during boot with error "Couldn't bind memory for BO front buffer"

[lspci]
00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 03)
	Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562]

[Report]
Regression since 2.4.1 driver seen in 2.5.1 driver on 82845G/GL[Brookdale-G]/GE hardware.  X hangs during start up and the following error message appears in the Xorg.0.log:

(EE) intel(0): Failed to pin front buffer: Cannot allocate memory

Fatal server error:
Couldn't bind memory for BO front buffer

Two other users indicated having a matching issue; one user was also on 845, the other on undeclared hardware.  http://ubuntuforums.org/showthread.php?t=998754
Comment 1 Gordon Jin 2008-12-09 17:33:33 UTC
Eric says this error appears if you've got a memory allocation setup that doesn't fit in your apperture, and DRI2 will likely fix it.
Comment 2 DougieFresh4U 2008-12-09 22:28:14 UTC
This is happening with the Intel 865G chipset as well
Comment 3 Marques Johansson 2008-12-17 03:29:09 UTC
Since I can't run X with the intel driver in its current state, I have been using the fbdev driver.  Here are some details and (attached) log entries.  I hope it can be of use:

sudo lspci -nnvv :

00:02.0 VGA compatible controller [0300]: Intel Corporation 82865G Integrated Graphics Controller [8086:2572] (rev 02) (prog-if 00 [VGA])
	Subsystem: Dell Device [1028:0151]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
	Region 2: I/O ports at ed98 [size=8]
	Capabilities: [d0] Power Management version 1
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: intelfb
	Kernel modules: intelfb

Some lines from dmesg  | grep -i -e intel -e drm -e agp:

[   21.064321] Linux agpgart interface v0.103
[   21.160181] agpgart-intel 0000:00:00.0: Intel 865 Chipset
[   21.160644] agpgart-intel 0000:00:00.0: detected 8060K stolen memory
[   21.162745] agpgart-intel 0000:00:00.0: AGP aperture is 128M @ 0xf0000000

[   74.884390] intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM chipsets
[   74.884403] intelfb: Version 0.9.6
[   74.884493] intelfb 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   74.884509] intelfb: 00:02.0: Intel(R) 865G, aperture size 128MB, stolen memory 8060kB
[   74.888847] intelfb: Initial video mode is 1024x768-32@70.
[  466.161347] [drm] Initialized drm 1.1.0 20060810
[  466.201873] intelfb 0000:00:02.0: setting latency timer to 64
[  466.210603] [drm] Initialized i915 1.6.0 20080730 on minor 0
[  822.739357] [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[  822.739365] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[  827.341749] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[  831.945566] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[ 1117.105987] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[ 1827.914660] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12


Comment 4 Marques Johansson 2008-12-17 03:30:38 UTC
Created attachment 21237 [details]
intel driver failing to load on :1 while :0 is occupied with intelfb/fbdev driver
Comment 5 Maximilian Engelhardt 2008-12-25 16:18:04 UTC
Created attachment 21481 [details]
Xorg.0.log

same problem here:
(EE) intel(0): Failed to pin back buffer: Cannot allocate memory

(Xorg.0.log ist attached)

lspci:
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

kernel: 2.6.28

using 'Option "Legacy3D" "false"' I get working 2D but no 3D:
[intel_init_bufmgr:497] Error initializing buffer manager.
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  3 (X_GLXCreateContext)
  Serial number of failed request:  24
  Current serial number in output stream:  27


This bug is also present in xf86-video-intel-2.5.99.1
Comment 6 Yu Yuwei 2008-12-25 19:21:56 UTC
Created attachment 21482 [details]
Failure log

The same on intel 855GME here,

x11-base/xorg-server-1.5.3
x11-drivers/xf86-video-intel-2.5.1
x11-libs/libdrm-2.4.1
media-libs/mesa-7.2
sys-kernels/gentoo-sources-2.6.28
Gentoo Linux


cat ~/Xorg.0.log | grep -C3 "(EE)"
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Dec 26 01:06:28 2008
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "Simple Layout"
--
(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x03bfe000 (pgoffset 15358)
(II) intel(0): xf86BindGARTMemory: bind key 5 at 0x03bff000 (pgoffset 15359)
(II) intel(0): xf86BindGARTMemory: bind key 6 at 0x059ff000 (pgoffset 23039)
(EE) intel(0): Failed to pin front buffer: Cannot allocate memory

Fatal server error:
Couldn't bind memory for BO front buffer
Comment 7 Andrés Becerra Sandoval 2009-01-15 06:25:26 UTC
I have the same setup than Yu Yuwei, and I want to add that if I boot a 2.6.27 kernel, xorg starts without problems.
It is only with the 2.6.28 kernel that I can reproduce the failure.
Comment 8 Karsten Heiken 2009-01-27 12:41:27 UTC
Created attachment 22281 [details]
"*ERROR* GTT full, but LRU list empty" in kernel.log

Same bug here.
It's actually pretty annoying...

No xf86-video-intel 2.5.0+ works for me.
I've got a Sony VAIO SR19XN with the 4500MHD (GM45, right?).
Comment 9 Karsten Heiken 2009-01-27 12:44:16 UTC
(In reply to comment #8)
> Created an attachment (id=22281) [details]
> "*ERROR* GTT full, but LRU list empty" in kernel.log
> 
> Same bug here.
> It's actually pretty annoying...
> 
> No xf86-video-intel 2.5.0+ works for me.
> I've got a Sony VAIO SR19XN with the 4500MHD (GM45, right?).
> 

Geez, hit the "Commit"-button too fast. Sorry guys.

It's a 2.6.28 kernel using (read: trying to use) xf86-video-intel 2.5.0, Xorg 1.5.3, libdrm 2.4.4.
Comment 10 Honza Lefty 2009-01-30 02:24:00 UTC
i am using intel X3100 (G965 i guess) and having the same error. The configuration:

dri2proto 1.99.3
xf86-dri-proto 2.0.4
mesa 7.3
xorg-server 1.5.99.901
xf86-video-intel 2.6.1
gentoo kernel 2.6.28-r1

it works with NoAccel with cca 150-200 FPS.
I use fbsplash on console (intelfb module). Tried unloading this module and starting X with no success.

the system is unusable after this error, no mouse/keyboard input response (sysrq and power button work i guess).

just tell me if you need more info/debugging. this bug is quite critical (not just) for me.
Comment 11 Honza Lefty 2009-02-04 07:08:37 UTC
I'm afraid DRI2 doesn't fix that as it was reported with 1.5.99 (and kernel 2.6.29) by several people. You can find one experimenting with several versions here: https://bugzilla.redhat.com/show_bug.cgi?id=469292
Comment 12 Gordon Jin 2009-02-04 19:56:24 UTC
(In reply to comment #11)
> I'm afraid DRI2 doesn't fix that as it was reported with 1.5.99 (and kernel
> 2.6.29) by several people. You can find one experimenting with several versions
> here: https://bugzilla.redhat.com/show_bug.cgi?id=469292

Is UXA used? (DRI2 takes effect only when UXA enabled)
Comment 13 Honza Lefty 2009-02-10 01:43:19 UTC
UXA hangs as well. see https://bugzilla.redhat.com/show_bug.cgi?id=469292#c42
Comment 14 Honza Lefty 2009-02-14 00:28:00 UTC
Hangs even with:
kernel-2.6.29-0.110.rc4.git3.fc11.i586
xorg-x11-server-Xorg-1.5.99.902-9.fc11.i386
xorg-x11-drv-i810-2.6.0-3.fc11.i386
libdrm-2.4.4-4.fc11.i386
mesa-libGL-7.3-2.fc11.i386
mesa-libGLU-7.3-2.fc11.i386
mesa-dri-drivers-7.3-2.fc11.i386
... and UXA enabled

logs can be found here: https://bugzilla.redhat.com/attachment.cgi?id=331797
original comment at RH bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=469292#c45

DRI2 really doesn't fix that ...
Comment 15 Honza Lefty 2009-02-15 00:05:39 UTC
Next try:

kernel-2.6.29-0.118.rc5.fc11.i586
xorg-x11-server-Xorg-1.5.99.902-10.fc11.i386
xorg-x11-drv-i810-2.6.0-5.fc11.i386
xorg-x11-drv-synaptics-1.0.0-4.fc11.i386
libdrm-2.4.4-4.fc11.i386
mesa-libGL-7.3-2.fc11.i386
mesa-libGLU-7.3-2.fc11.i386
mesa-dri-drivers-7.3-2.fc11.i386

"The keyboard does not hang.  chvt works.  I can use
ctrl-alt-F2 to change to a vt and blindly log in (verified that mingetty
changes to bash using ps in a ssh session).  Despite changing vt's and back to
vt7, the backlight remains off.  However "xdpyinfo -display :0" hangs when
ssh'ing into the laptop.  Though the mouse is not visible, moving the mouse in
the direction of the xterm and typing commands doesn't produce any results 
(example: "ls > /tmp/x" doesn't create file /tmp/x)."

messages:
Feb 14 21:36:19 blu kernel: [drm] Initialized drm 1.1.0 20060810
Feb 14 21:36:19 blu kernel: pci 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11
(level, low) -> IRQ 11
Feb 14 21:36:19 blu kernel: [drm] Initialized i915 1.6.0 20080730 on minor 0
Feb 14 21:36:19 blu kernel: [drm:i915_irq_emit] *ERROR* i915_irq_emit called
without lock held, held  0 owner (null) dce600f0

end of xorg log:
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x007df000 (pgoffset 2015)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x00800000 (pgoffset 2048)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00024fff: HW cursors (20 kB)
(II) intel(0): 0x00025000-0x00124fff: fake bufmgr (1024 kB)
(II) intel(0): 0x007df000:            end of stolen memory
(II) intel(0): 0x007df000-0x007dffff: overlay registers (4 kB, 0x000000001e45f000 physical
)
(II) intel(0): 0x00800000-0x00bfffff: front buffer (4096 kB)
(II) intel(0): 0x08000000:            end of aperture
_fence_emit_internal: drm_i915_irq_emit: -22

original: https://bugzilla.redhat.com/show_bug.cgi?id=469292#c46 (attachment is gzipped twice)
Comment 16 Zdenek Kabelac 2009-02-16 02:39:13 UTC
I think I'm seeing now the same bug:


Even shortly after boot:

[  223.795729] gnome-screensav used greatest stack depth: 3288 bytes left
[  563.731434] [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[  563.731441] [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_evict_something] *ERROR* inactive empty 1 request empty 1 flushing empty 1


My machine is T61, C2D, 4GB RAM.
I'm running  2.6.29-rc5, x86_64, UXA acceleration

Xorg server from Fedora Rawhide:xorg-x11-server-Xorg-1.5.99.902-10.fc11.x86_64 

drm library commit: eb78c53aa1a980e60c0dd1f2d0d2f04cb9cb2622
xf86-video-intel: 3012d85cc5eb58c2447e93c05c39dc14feaae988
(both relatively recent I guess)

I only see this dmesg error message - there is no error message in Xorg.0.log yet
Comment 17 Marios Andreopoulos 2009-02-18 10:18:47 UTC
I confirm this bug. I think it is related to kernel version 2.6.28 or higher since it does not happen with kernel 2.6.27.

It happens with every combination I have tried: xf86-video-intel (2.5.0, 2.5.1, 2.6.1), xorg-server (1.5.3, 1.5.99.902), dri2proto (1.1, 1.99.3), mesa (7.2, 7.3), libdrm (2.4.3, 2.4.4).

lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
        Subsystem: Fujitsu Siemens Computers Device 1108                                                                                     
        Flags: bus master, fast devsel, latency 0, IRQ 16                                                                                    
        Memory at fc000000 (64-bit, non-prefetchable) [size=1M]                                                                              
        Memory at d0000000 (64-bit, prefetchable) [size=256M]                                                                                
        I/O ports at 1800 [size=8]                                                                                                           
        Expansion ROM at <unassigned> [disabled]                                                                                             
        Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable-                                                                               
        Capabilities: [d0] Power Management version 3 


Sorry but I do not know which info would help, if there is something you need please ask.
Comment 18 Marios Andreopoulos 2009-02-23 08:30:21 UTC
An update over my previous comment.
I edited xorg.conf and set explicitly for the intel driver to use UXA acceleration (it doesn't use it automatically). That way I am able to boot to a 2.6.28 kernel and use my desktop. There are some problems but X is up and running and this is generally considered as a good thing!

Sorry I hadn't tried this earlier since it is mentioned in the comments above, but I was somewhat confused by the intel driver's documentation as the man page (up to version 2.6.1) doesn't include UXA as a possible option to AccelMethod.
Comment 19 Honza Lefty 2009-02-26 09:12:38 UTC
i upgraded kernel to vanilla 2.6.29-r6 and UXA relatively works. 

dmesg:
[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_gem_evict_something] *ERROR* inactive empty 1 request empty 1 flushing
 empty 1
-↑- several times
[drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 0

FPS cca 600 in glxgears with vblank_mode=0.
Comment 20 Yu Yuwei 2009-03-09 18:32:56 UTC
I test xf86-video--intel-2.6.3 with gentoo-sources-2.6.28-r3 (which is 2.6.28.7) and got "could not pin back buffer" error:

Xorg.0.log:
(II) intel(0): [DRI] installation complete
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x02ff4000 (pgoffset 12276)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x02ff5000 (pgoffset 12277)
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x02ff9000 (pgoffset 12281)
(II) intel(0): xf86BindGARTMemory: bind key 3 at 0x02ffa000 (pgoffset 12282)
(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x02ffe000 (pgoffset 12286)
(II) intel(0): xf86BindGARTMemory: bind key 5 at 0x02fff000 (pgoffset 12287)
(II) intel(0): xf86BindGARTMemory: bind key 6 at 0x059ff000 (pgoffset 23039)
(EE) intel(0): Failed to pin back buffer: Cannot allocate memory

Fatal server error:
Couldn't bind memory for BO back buffer

(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4
(II) intel(0): xf86UnbindGARTMemory: unbind key 5
(II) intel(0): xf86UnbindGARTMemory: unbind key 6

dmesg | grep drm:
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20080730 on minor 0
[drm:i915_setparam] *ERROR* unknown parameter 4
[drm:i915_getparam] *ERROR* Unknown parameter 6
[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_setparam] *ERROR* unknown parameter 4
[drm:i915_getparam] *ERROR* Unknown parameter 6
[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[drm:i915_gem_object_pin] *ERROR* Failure to bind: -12<3>[drm:i915_setparam] *ERROR* unknown parameter 4
[drm:i915_getparam] *ERROR* Unknown parameter 6
[drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
[drm:i915_gem_object_pin] *ERROR* Failure to bind: -12

seems the drm(20060810) is not compatible with new i915(20080730).
Comment 21 Bryce Harrington 2009-03-19 00:05:48 UTC
Gordon, please would you mind giving us an update on the status of this bug?
Comment 22 Karsten Heiken 2009-03-19 03:17:19 UTC
I also suffered from this bug.
But recently I found out, that it only happened, when there is a "Virtual"-option in my Xorg.conf:
Section "Screen"
	Identifier "Screen0"
	Device     "Device0"
	Monitor    "LVDS"
	DefaultDepth     24
	SubSection "Display"
		Modes "1280x800_60"
		Virtual 2960 1056
	EndSubSection
EndSection

When I removed the Virtual-option, everything went fine.

The other day i reinstalled my system (Arch Linux) and installed the newest packages from the testing-repository.
Namely those packages are:
xf86-video-intel 2.6.99.902-1
libdrm 2.4.5-2
mesa 7.3-2
xorg-server 1.6.0-1

After a few changes in my Xorg.conf I came to these settings:
Section "Device"
	Identifier  "Device0"
	Driver "intel"
	Option "Legacy3D" "true"
	Option "DRI" "true"
        Option "AccelMethod" "uxa"
        Option "ExaNoComposite" "true"    
EndSection

I put the Virtual-section back in - I need my 22" lcd ;)

And what do my eyes see?
Everything works!

I also tried the latest xf86-video-intel via GIT. Same thing there.
I installed ioquake3 - and woohoo! 90fps.

Everything's great right now.

Maybe someone could try those Xorg.conf-settings and the latest git-version.

Regards,
karsten
Comment 23 Gordon Jin 2009-03-21 19:50:47 UTC
(In reply to comment #21)
> Gordon, please would you mind giving us an update on the status of this bug?

I don't have more update. Eric owns this bug.
Comment 24 Yu Yuwei 2009-03-22 20:41:08 UTC
(In reply to comment #22)
> I also suffered from this bug.
> But recently I found out, that it only happened, when there is a
> "Virtual"-option in my Xorg.conf:
> Section "Screen"
>         Identifier "Screen0"
>         Device     "Device0"
>         Monitor    "LVDS"
>         DefaultDepth     24
>         SubSection "Display"
>                 Modes "1280x800_60"
>                 Virtual 2960 1056
>         EndSubSection
> EndSection
> 
> When I removed the Virtual-option, everything went fine.
> 
> The other day i reinstalled my system (Arch Linux) and installed the newest
> packages from the testing-repository.
> Namely those packages are:
> xf86-video-intel 2.6.99.902-1
> libdrm 2.4.5-2
> mesa 7.3-2
> xorg-server 1.6.0-1
> 
> After a few changes in my Xorg.conf I came to these settings:
> Section "Device"
>         Identifier  "Device0"
>         Driver "intel"
>         Option "Legacy3D" "true"
>         Option "DRI" "true"
>         Option "AccelMethod" "uxa"
>         Option "ExaNoComposite" "true"    
> EndSection
> 
> I put the Virtual-section back in - I need my 22" lcd ;)
> 
> And what do my eyes see?
> Everything works!
> 
> I also tried the latest xf86-video-intel via GIT. Same thing there.
> I installed ioquake3 - and woohoo! 90fps.
> 
> Everything's great right now.
> 
> Maybe someone could try those Xorg.conf-settings and the latest git-version.
> 
> Regards,
> karsten
> 

This solution is not workable for me with xf86-video-intel-2.6.1 and kernel-2.6.28.8 :(
Comment 25 Carl Worth 2009-05-20 15:43:34 UTC
(In reply to comment #15)

> _fence_emit_internal: drm_i915_irq_emit: -22

I just replicated this part of the bug at least, (with all the latest userspace, such as xf86-video-intel 2.7.99 from git), and a non-GEM Debian kernel (2.6.26-2-686).

Eric suggests that when the userspace opens the drm and finds that it's non-GEM it should just close it. I'll attempt that here and report back.

-Carl
Comment 26 Carl Worth 2009-05-26 16:16:31 UTC
(In reply to comment #25)
> (In reply to comment #15)
> 
> > _fence_emit_internal: drm_i915_irq_emit: -22
> 
> I just replicated this part of the bug at least, (with all the latest
> userspace, such as xf86-video-intel 2.7.99 from git), and a non-GEM Debian
> kernel (2.6.26-2-686).
> 
> Eric suggests that when the userspace opens the drm and finds that it's non-GEM
> it should just close it. I'll attempt that here and report back.

Eric had some half-finished patches for this which I finished and pushed (see below).

With these patches applied, the latest driver from git now runs just fine on the non-GEM Debian kernel (2.6.26-2-686). I'd be very interested if other people that have experienced the bugs reported here could try using the latest driver and report back whether the bug is fixed.

I'll also consider cherry-picking the relevant commits here to the 2.7 branch for an upcoming 2.7.2 release.

-Carl
Comment 27 Carl Worth 2009-05-26 16:20:51 UTC
(In reply to comment #26)
> Eric had some half-finished patches for this which I finished and pushed (see
> below).

Here's the "see below" part I forgot to add with the last comment.

-Carl

commit 8e942b70cb9a784b3f1311affd6fc74c4bcf68bb
Author: Carl Worth <cworth@cworth.org>
Date:   Thu May 21 13:12:52 2009 -0700

    Revert "Rely on BO pixmaps being present in acceleration paths."
    
    This reverts commit 4653a7db622ad54a3182d93c81331765d930db34.
    
    Eric was getting a little too ambitious about our brave, new world.
    We do still want the driver to work with old, non-GEM kernels
    after all.

commit 1a039f4371bec455cad43f0fb7b329f2ee09a974
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Apr 27 17:45:02 2009 -0700

    Fold GEM detection into DRM master open.
    
    We don't have anything to do with the DRM unless it's GEM-enabled, unless
    we were to support GEM-but-not-DRI2, which doesn't seem useful.
    
    Compilation fixes by Carl Worth <cworth@cworth.org>

commit a04a51c9bb6066454e0fda3c7897f97dab436358
Author: Eric Anholt <eric@anholt.net>
Date:   Mon Apr 27 17:29:36 2009 -0700

    Open the DRM and keep the handle throughout server startup to finish.
    
    This will let us configure the server from start to finish with the
    most pertinent information available (KMS vs UMS, DRI2 vs non-DRI).  Also,
    we now close the DRI2 fd at terminate, which we didn't before.
    
    This duplicates some code from DRI1 for getting a master FD like I'd done in
    DRI2, but given that we weren't loading DRI1 ourselves, this is also a
    bogosity cleanup, and avoids allocating the extra DRI1 private.
Comment 28 Gordon Jin 2009-06-09 12:07:28 UTC
Could any of the reporters confirm this problem still exists with the latest xf86-video-intel driver and a KMS kernel? If so, I'll increase the priority and target for Q2 release (2.8).
Comment 29 aguertin+freedesktop 2009-06-09 14:53:25 UTC
I used to see this with a 2.5-era xf86-video-intel and now I do not with current git stuff and KMS.

In fact, I get an explicit success message:
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x00000000:            start of memory manager
(II) intel(0): 0x03800000-0x03ffffff: front buffer (8192 kB) X tiled
(II) intel(0): 0x03000000-0x03004fff: HW cursors (20 kB)
(II) intel(0): 0x07fff000:            end of memory manager

This is on 845.
Comment 30 Gordon Jin 2009-06-24 00:07:12 UTC
So I assume it has been fixed.
If anyone still see this with a new driver (>=2.6.99.901) and KMS kernel, please reopen.
Comment 31 Gordon Jin 2009-06-24 00:07:52 UTC
(In reply to comment #30)
> So I assume it has been fixed.
> If anyone still see this with a new driver (>=2.6.99.901)

typo. I meant 2.7.99.901.

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.