Created attachment 9790 [details]
Xorg log when cachelines takes default value(bad)

Created attachment 9791 [details]
Xorg configuration file with the proposed cachelines value.

Created attachment 9792 [details]
Current (good) Xorg log.

Someone on the xorg list pointed out that this only seems to happen when increasing the virtual resolution in xorg.conf. Can you confirm that? If so, maybe the driver doesn't take the virtual resolution into account properly when calculating the default CacheLines value.

(In reply to comment #4)
> Someone on the xorg list pointed out that this only seems to happen when
> increasing the virtual resolution in xorg.conf. 

This issue has also been reported as http://bugs.debian.org/423416, and the xorg.conf included there doesn't change the virtual resolution afaics.

*** Bug 11157 has been marked as a duplicate of this bug. ***

Created attachment 11092 [details]
Fresher Xorg log.

This is just to provide up to date log with the latest intel git version. The situation stays the same, DRI works, but still there are some warnings in the log.

I too had this problem 20minutes ago, I am using a xorg-configuration where I have 2 Monitor-, 2 Device- and 2 Screen-Sections. Adding VideoRam 32768 (16384 was not enough) to both Device-Sections _solved_ this error.

$ cat /etc/X11/xorg.conf
Section		"ServerLayout"
	Identifier	"l0"
	Screen		"s0"
	Screen		"s1"	LeftOf	"s0"
	InputDevice	"p0"	"CorePointer"
	InputDevice	"k0"	"CoreKeyboard"
EndSection

Section		"ServerFlags"
	Option		"XkbDisable"	"true"
	Option		"BlankTime"	"0"
	Option		"StandbyTime"	"0"
	Option		"SuspendTime"	"0"
	Option		"OffTime"	"12"
EndSection

Section		"Files"
	FontPath	"/usr/share/fonts/terminus"
	FontPath	"/usr/share/fonts/corefonts"
	FontPath	"/usr/share/fonts/intlfonts"
	FontPath	"/usr/share/fonts/freefonts"
	FontPath	"/usr/share/fonts/sharefonts"
	FontPath	"/usr/share/fonts/misc"
	FontPath	"/usr/share/fonts/Type1"
	FontPath	"/usr/share/fonts/ttf-bitstream-vera"
	FontPath	"/usr/share/fonts/75dpi"
	FontPath	"/usr/share/fonts/100dpi"
	ModulePath	"/usr/lib/xorg/modules"
	RgbPath		"/usr/share/X11/rgb"
EndSection

Section		"Module"
	Load		"dbe"
	SubSection	"extmod"
		Option		"omit xfree86-dga"
	EndSubSection
	Load		"glx"
	Load		"dri"
	Load		"freetype"
	Load		"type1"
EndSection

Section		"InputDevice"
	Identifier	"k0"
	Driver		"kbd"
	Option		"AutoRepeat"	"200	80"
EndSection

Section		"InputDevice"
	Identifier	"p0"
	Driver		"mouse"
	Option		"Protocol"	"ImPS/2"
	Option		"Device"	"/dev/input/mice"
	Option		"ZAxisMapping"	"4 5 6 7"
EndSection

Section		"Device"
	Identifier	"c0"
	Driver		"i810"
	BusID		"PCI:0:2:0"
	Option		"MonitorLayout"		"CRT,LFP"
	Option		"DevicePresence"	"true"
	VideoRam	32768
	Screen		0
EndSection

Section		"Monitor"
	Identifier	"m0"
	Option		"DPMS"
EndSection

Section		"Screen"
	Identifier	"s0"
	Device		"c0"
	Monitor		"m0"
	DefaultDepth	24
	SubSection	"Display"
		Modes		"1024x768"
		ViewPort	0	0
		Depth		24
	EndSubSection
EndSection

Section		"Device"
	Identifier	"c1"
	Driver		"i810"
	BusID		"PCI:0:2:0"
	VideoRam	32768
	Screen		1
EndSection

Section		"Monitor"
	Identifier	"m1"
	Option		"DPMS"
EndSection

Section		"Screen"
	Identifier	"s1"
	Device		"c1"
	Monitor		"m1"
	DefaultDepth	24
	SubSection	"Display"
		Modes		"1280x1024"
		ViewPort	0	0
		Depth		24
	EndSubSection
EndSection
$ xdriinfo 
Screen 0: i915
Screen 1: not direct rendering capable.

(In reply to comment #8)
> Adding VideoRam 32768 (16384 was not enough) to both Device-Sections _solved_
> this error.

As of xf86-video-intel 2.0, the VideoRam directive can only decrease the amount of memory available to the driver, never increase it, so it's generally a bad idea to use it at all.


P.S. please don't paste files into comments.

P.P.S. Raúl, there have been recent changes in the xf86-video-intel GIT master branch that I think might have an impact on this problem. Can you still reproduce the problem with that?

I do reproduce the problem. If I don't add the Cachelines option, the texture memory is not allocated and DRI is not enabled. Look the attached logs. Xorg.0.log uses the cachelines option, Xorg.0.log.old doesn't

Created attachment 11359 [details]
Xorg log without the cachelines option. DRI disabled.

Created attachment 11360 [details]
Xorg log with the cachelines option. DRI enbled.

Both xorg log files have been obtained using and uptodate git version.

Hello:

Ok guys, I think I have one important track here. I get to build the git latest driver and following Keith advises, I removed the xorg.conf files. You know, memory allocation worked finally!. That make me think since I had previously tried again with and without cachelines parameter.

What I did is keep my xorg.conf file and get rid of the virtual directive and the cachelines option. That way it works. So I think the driver is probably not taking seriously the virtual directive.

I'm attaching Xorg log for all the possibilities.

Thanks.

Created attachment 11465 [details]
Xorg log with the cachelines option. DRI enbled.

Created attachment 11466 [details]
Xorg log without the cachelines option. DRI disabled.

Created attachment 11467 [details]
Log without the cachelines option and without virtual directive.

Please ask for Xorg log without xorg.conf file if you need it.

Sounds like this particular issue has been fixed.

Please open a new bug if you find that the "virtual" option isn't working for you (works for me at least).

Generally you shouldn't need VideoRAM or cachelines directives anymore.  If you do, I'd consider *that* a bug. :)