This bug has been reported by Dylan Thurston on the Debian BTS and several people confirmed the same behavior. It also got mentioned at the end of #11453.
Since Intel driver 2.2 (actually 2.1.99 too), enabling a virtual screen larger than 2048 results in a lockup of the server at startup. Removing the Virtual line in the config solves the problem. Option NoAccel works around it too.
These people were OK with having DRI disabled with earlier drivers because of a too large virtual screen. Having to disable 2D acceleration now is far more annoying :)
There's one log exhibiting the problem at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=Xorg.bug.log;att=1;bug=451570
It has been observed at least on 915GM/GMS/910GML and 945GM/GMS/940GML.
This seems a big issue. However, I'm not seeing this issue on my 915GM, with intel 2.2 + server 1.4. I only see dri disabled but X works with EXA.
Are the intel driver and server in Debian the same as those in fd.o?
Debian's 2:2.2.0-1 driver contains fd.o 2.2 + the next commit (4a2b0f340357c4ca58dc9586fad1337b83966362,
Fix typo in 1920x1080 resolution entry).
On the Xserver side, we currently have a snapshot of 1.4.1, but some people also reproduced with 1.4 and only a couple patches.
FWIW, the guy that observed the problem on 915 had "Virtual 3000 1600" (xorg.conf available in http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=451570)
"Virtual 3000 1600" also works for me.
I also reported this problem to the Debian BTS. I am using a 945GM (Compaq nx6320 laptop).
You can see my xorg.conf in that report, and a Xorg.log of the failure case when I uncomment the "Virtual 2880 2048" line in my xorg.conf (an attachment to one of the messages).
If EXA simply will not work with Virtual > 2048 then perhaps it should not be enabled in this situation. Unfortunately, though it would be nice to have DRI, it is more important to me to have both screens - and many other people as well, I'm sure.
Created attachment 12911 [details] [review]
Does this xserver patch fix it?
It is entirely possible that I have screwed up somewhere, but when I apply your patch to the current Debian xserver-xorg-core and rebuild it I unfortunately don't have a lot of luck :-(
Created attachment 14132 [details] [review]
fix bo_list corruption
please take a try on this patch.
This patch is upstream now... Andrew or Brice, can you test again?
I pingued my users when Hong Liu posted the patch. Only one of them tested it so far. He said it *didn't* help, no change in the behavior (no change in the log either). I will report here when the other ones will reply.
Created attachment 14171 [details]
Log file of Xorg failing
I didn't have a chance to look at this until tonight, unfortunately, but it seems that the patch is included in the latest Debian xserver-xorg-video-intel, so I was saved the effort of applying it myself :-)
With *no* AccelMethod specified in my xorg.conf, but *with* Virtual 2880 2048 present the XServer fails to start, with the log file attached.
It is also worth mentioning that I am now able to set Option NoAccel and restart X without having to reboot. Previously the lockup left the video in such a state that a reboot was required.
(In reply to comment #10)
> Created an attachment (id=14171) [details]
> Log file of Xorg failing
> I didn't have a chance to look at this until tonight, unfortunately, but it
> seems that the patch is included in the latest Debian xserver-xorg-video-intel,
> so I was saved the effort of applying it myself :-)
actually it isn't, the uploaded 2:220.127.116.11-1 actually has an older version of the code. Please try again with 2:18.104.22.168-2 (which i'm uploading now).
Ah. Bugger :-)
I checked the Git repo and it was in there, so I assumed it was in the new update I had just installed a few minutes previously.
Chung-chieh Shan confirmed that 22.214.171.124 (the right one) still has the problem. Config and log available at http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=46;bug=451570
I guess there were at least two different issues here. Dylan Thurston says his problem is fixed now (config and log at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451570#61) while comment #13 shows that some people still have a lockup.
After talking with my users, it looks like the lockup *at startup* is fixed. The other users are experiencing a lockup a bit after the startup:
* 2 users report a lockup about 10s after startup
* 1 user gets a lockup when 'mail-notification' starts and puts up a pop-up window
I have no idea how EXA + virtual>2048 could cause such lockups...
So does using the XAA AccelMethod also work around the problem?
Created attachment 14465 [details] [review]
Only limit CRTC size if EXA is enabled
Even back in old versions (2.1) we were limiting the CRTC range to 2048x2048, so I'm not sure why this problem would suddenly start biting you.
However, this patch applies the 2048 limit only when EXA is in use, otherwise it uses an 8192 limit, maybe it'll prevent the hangs you're seeing. It also falls back to XAA if the width is > 2048; hopefully I got the logic right.
Option "MigrationHeuristic" "greedy"
In the device section solves the issue on both debian sid and ubuntu hardy
(In reply to comment #18)
> Option "MigrationHeuristic" "greedy"
> In the device section solves the issue on both debian sid and ubuntu hardy
That's probably just luck, due to greedy never actually attempting acceleration of a problematic pixmap.
Has it been verified whether this problem happens with xserver Git master? If it doesn't, can the patch I attached be tested again against the 1.4 branch, making sure it really is used?
chantra and other bug reporter, please respond to comment# 17 and comment# 19. thanks.
Created attachment 14853 [details]
A log of an X session which locked up
In reply to comment #17, when I apply that patch to the current Debian xserver-xorg-video-intel package from unstable I still see the previous behaviour, to wit:
- X starts fine and displays the GDM login
- I log in and about ten seconds later (while everything is still starting up) the lockup occurs.
At one time I thought the lockup was happening exactly as the theming was being applied to the desktop items, but after watching this a number of times it is clear that it happens somewhat later than that.
On this occasion I logged in and started X with 'startx' in order to not get my X log overwritten by GDM restarting and other such stuff. The attached log is the output of startx in that situation.
Finally, regarding "NoAccel" vs. "XAA": either work fine for me. The lockup only occurs if I choose "EXA" or have all of them commented out.
As you can see from the log file this is:
X.Org X Server 126.96.36.199 (i.e. xorg-server 2:1.4.1~git20080131-1)
From the main Xorg log file, the intel driver version seems to be:
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
compiled for 188.8.131.52, module version = 2.2.1
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 2.0
(except with that patch 14465 applied).
Ok, so I must not have the fallback code quite right. I'll take a look at your log and see if I can fix the patch.
*** Bug 14476 has been marked as a duplicate of this bug. ***
God, our startup logic is a mess... can you attach the log when you run with the '-verbose' option? I want to be sure the code I think is running actually is.
xserver has already been awared with driver maxX/Y limit and intel driver has no UTS implement.
We can do 2048 limit check earlier before DRI init, that seems to be the only fix we need for this.
Created attachment 15447 [details] [review]
disable DRI if width > 2048 before dri init
Close this, as patches are upstream. Pls test and verify.
I am wondering, is the issue also happening when height>2048?
In that case, shouldn't the if condition being tested on
if (!IS_I965G(pI830) && (pScrn->displayWidth > 2048 || pScrn->displayHeight > 2048))
I don't believe there is many people running one screen above the other one, but the issue will still happen for them with the patch innit?
I applied it and can verify X is not crashing anymore
made a debdiff against xserver-xorg-video-intel-2.2.1-1ubuntu6