Bug 13376

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).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452357

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.

Thanks :-)

Andrew McMillan.

Created attachment 12911 [details] [review]
Possible fix

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 :-(

Regards,
Andrew McMillan.

Created attachment 14132 [details] [review]
fix bo_list corruption

please take a try on this patch.

Thanks,
Hong

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.

Thanks,
Andrew McMillan.

(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:2.2.0.90-1 actually has an older version of the code.  Please try again with 2:2.2.0.90-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.

Sorry.

Chung-chieh Shan confirmed that 2.2.0.90 (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.

As per
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/188178/comments/6

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 1.4.0.90 (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 1.4.0.90, 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).

Thanks,
Andrew McMillan.

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.

@wang:

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?

@wang:
I applied it and can verify X is not crashing anymore 
made a debdiff against xserver-xorg-video-intel-2.2.1-1ubuntu6

https://bugs.launchpad.net/debian/+source/xserver-xorg-video-intel/+bug/188178/comments/17

thanks