Bug 21190 - [915/945 uxa] fail to startx with virtual size >2048x2048
[915/945 uxa] fail to startx with virtual size >2048x2048
Status: VERIFIED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
unspecified
Other Linux (All)
: medium major
Assigned To: Keith Packard
Xorg Project Team
:
: 21571 23237 25075 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-14 19:48 UTC by liuhaien
Modified: 2009-12-01 07:09 UTC (History)
11 users (show)

See Also:


Attachments
xorg.0.log (12.03 KB, text/plain)
2009-04-14 19:48 UTC, liuhaien
no flags Details
xorg conf file (3.76 KB, text/plain)
2009-04-14 19:49 UTC, liuhaien
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description liuhaien 2009-04-14 19:48:39 UTC
Created attachment 24805 [details]
xorg.0.log

System Environment:
--------------------------
Host:		x-aspire1
Arch:		i386
Platform:		acer aspire1
Kernel_version:		2.6.29.1
Libdrm:		(master)07646002c6835537c6ae44ef9b3f8480762279b8
Mesa:		(mesa_7_4_branch)de197cf991416f0cd65ad2e2d2ca9aa599b52075
Xserver:	(server-1.6-branch)60c161545af80eb78eb790a05bde79409dfdf16e
Xf86_video_intel:		(2.7)121bd7ff7cfd9a43fbb61fa56f06ba2d2b55035e
Kernel:       (drm-intel-2.6.29)0aa7e8a61658193f90198d579c5ef8297b45be9b

Bug detailed description:
-------------------------
If I start X with the virtual size (>2048x2048) on i915 platfroms,it crashes with errors as below:

(EE) intel(0): Cannot support > 2048 vertical lines. disabling acceleration.
(EE) intel(0): Failed to init memory manager
Setting master
failed to add fb

Dmesg shows:
[drm:drm_mode_addfb] *ERROR* mode new framebuffer width not within limits


this issue happens on 855gm,915gm,945gm and aspire1. but works well on g45,gm965 and gm45.

reproduce steps:
------------------------
1.xinit&
Comment 1 liuhaien 2009-04-14 19:49:02 UTC
Created attachment 24806 [details]
xorg conf file
Comment 2 liuhaien 2009-04-14 19:49:58 UTC
and it exists with KMS and UMS.
Comment 3 Gordon Jin 2009-05-05 18:00:23 UTC
*** Bug 21571 has been marked as a duplicate of this bug. ***
Comment 4 Bryce Harrington 2009-05-27 02:56:27 UTC
A backtrace is available here:
http://launchpadlibrarian.net/24551278/ThreadStacktrace.txt

briefly:

#0  0xb78e3309 in drm_intel_bo_reference () from /usr/lib/libdrm_intel.so.1
#1  0xb794588b in i830_set_pixmap_bo (pixmap=0x8465190, bo=0x0)
    at ../../src/i830_exa.c:772
	old_bo = <value optimized out>
#2  0xb7920ab8 in i830_xf86crtc_resize (scrn=0x83efef0, width=1152, 
    height=864) at ../../src/i830_driver.c:1178
	new_front = <value optimized out>
	old_front = (i830_memory *) 0x843e810
	mem_box = {x1 = 0, y1 = 0, x2 = 2048, y2 = 864}
	screen = (ScreenPtr) 0x843e350
	old_x = 3120
	old_y = 1050
	old_width = 4096
Comment 5 Jesse Barnes 2009-05-27 03:36:58 UTC
Does this also happen if you just set the accelmethod to none in xorg.conf?
Comment 6 liuhaien 2009-05-30 18:58:17 UTC
(In reply to comment #5)
> Does this also happen if you just set the accelmethod to none in xorg.conf?
> 

yes,and it does happen without acceleration.
Comment 7 Keith Packard 2009-07-11 09:33:45 UTC
I've pushed driver fixes for this to master in patch:

d655a3ff423e69c19a5dc07140cbf3caaa32cb86 Remove NoAccel support.

There's an associated fix necessary in the kernel to bump the framebuffer limit from 2048 to 4096 for KMS which should land shortly.
Comment 8 Geir Ove Myhr 2009-07-11 17:58:25 UTC
(In reply to comment #7)
> I've pushed driver fixes for this to master in patch:
> 
> d655a3ff423e69c19a5dc07140cbf3caaa32cb86 Remove NoAccel support.

Shouldn't the NoAccel option also be removed from man/intel.man then?
Comment 9 Keith Packard 2009-07-11 22:49:59 UTC
> Shouldn't the NoAccel option also be removed from man/intel.man then?

Not quite -- the i810/i815 portion of the driver still supports the NoAccel option.
Comment 10 Gordon Jin 2009-07-12 23:16:14 UTC
(In reply to comment #7)
> I've pushed driver fixes for this to master in patch:
> 
> d655a3ff423e69c19a5dc07140cbf3caaa32cb86 Remove NoAccel support.
> 
> There's an associated fix necessary in the kernel to bump the framebuffer limit
> from 2048 to 4096 for KMS which should land shortly.

Keith, I see the xf86-video-intel fix, but I can't find the kernel fix in drm-intel-next.

X still fails to start (with 4096 set) with message: "failed to add fb"
 

Comment 11 Gordon Jin 2009-07-14 19:09:47 UTC
I've seen the kernel fix in drm-intel-next:
drm/i915: Allow frame buffers up to 4096x4096 on 915/945 class hardware

And verified 945GM works with the fixes for both KMS and UMS.

Comment 12 Gordon Jin 2009-07-14 19:10:12 UTC
But 8xx still suffers so I'm changing the summary and decreasing priority.
Comment 13 Keith Packard 2009-07-14 19:43:06 UTC
8xx cannot scanout from buffers wider that 8192 bytes, limiting it to 2048 pixels. Hence the limit must remain lower for 8xx chips.
Comment 14 Gordon Jin 2009-08-11 17:51:29 UTC
*** Bug 23237 has been marked as a duplicate of this bug. ***
Comment 15 Gordon Jin 2009-11-22 17:18:14 UTC
*** Bug 25075 has been marked as a duplicate of this bug. ***
Comment 16 Carl Michal 2009-11-24 22:44:25 UTC
In comment #7, it sounds like there is a fix needed for this to work with KMS enabled.  With all components of the 2009Q3 release (but kernel 2.6.32-rc7) this still seems to be missing - with KMS enabled, xrandr tells me the screensize is limited to 2048x2048 still, but with KMS disabled, that goes up to 4096x4096.

Did that fix get left behind somewhere?

I ask partly because it appears framebuffer compression gets disabled (according to Xorg.0.log anyway) if KMS is not enabled, so it would appear that at the moment one has to choose between bigger screens (no KMS) or framebuffer compression (KMS).
Comment 17 Keith Packard 2009-11-24 23:04:56 UTC
For KMS, you need kernel patch 5e4d6fa72619aeea271d2ad704757717b06e291a5e4d6fa72619aeea271d2ad704757717b06e291a as well. That shipped in 2.6.31.
Comment 18 Shuang He 2009-11-24 23:08:26 UTC
(In reply to comment #17)
> For KMS, you need kernel patch
> 5e4d6fa72619aeea271d2ad704757717b06e291a5e4d6fa72619aeea271d2ad704757717b06e291a
> as well. That shipped in 2.6.31.
> 

Guess it's a Copy&Paste error.
should be 5e4d6fa72619aeea271d2ad704757717b06e291a
Comment 19 Carl Michal 2009-11-24 23:30:04 UTC
Sorry, I'm a moron.  Thanks for the quick answers.

I got that backwards.  It appears to me as though large screens only work if KMS is enabled, and framebuffer compression gets disabled if KMS is enabled.
(on a 945GME - in a dell mini-9).

Comment 20 Gordon Jin 2009-11-25 00:05:24 UTC
(In reply to comment #19)
> Sorry, I'm a moron.  Thanks for the quick answers.
> 
> I got that backwards.  It appears to me as though large screens only work if
> KMS is enabled, 

That's expected.

> and framebuffer compression gets disabled if KMS is enabled.

That's probably bug#23767. I'm going to reopen it.