Created attachment 18833 [details]
xorg conf file

and our drmmodule use below commit:
DrmR:		(drm-next)721f1651546231c4e53a1afe31e15e8234b076e0
it happens on our GM45,G965,G33 and 945g.

I guess this has been fixed in the latest commit:

commit d8d95d8c71f2cd4bab277f44132ece7963714a5b
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Sep 11 16:11:46 2008 -0700

    Fix build failures that should have been in the previous merge commit.

Oh, please ignore my comment#3. It's on xf86-video-intel dri2 branch.

Anyone see this regression too? Any idea?

The only reason I can imagine is Eric's libdrm change yesterday. Haien, can you confirm?

I don't have this problem on my 915G, so fixing your building. Pull all needed repos. This bug should be closed.

I try to rebuild all components using the latest commit.and this issue still exists on our G33 ,G43, GM45 Q965 and GM965.
I bisect and find when using below commit,it can work well:
libdrm:master 738e36acbce24df0ccadb499c5cf62ccb74f56df
xf86-video-intel:master 738e36acbce24df0ccadb499c5cf62ccb74f56df

I can reproduce it with a non-GEM DRM module.

Created attachment 18837 [details] [review]
a patch to fix the crash when using non-GEM DRM module.

Created attachment 18838 [details] [review]
a patch to fix the crash when using non-GEM DRM module.

Actually I am confused by this bugreport:

First of all you recognize in Xorg.0.log this error message, which you make responsible for the error:

(EE) Failed to load module "dri2" (module requirement mismatch, 0)

If you scroll up in the Xorg.0.log you'll see the reason why this fails:

(II) Loading /opt/X11R7/lib/xorg/modules/extensions//libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
	compiled for 1.5.99.1, module version = 1.0.0
	ABI class: X.Org Server Extension, version 1.1
(EE) module ABI major version (1) doesn't match the server's version (2)
(II) UnloadModule: "dri2"
(II) Unloading /opt/X11R7/lib/xorg/modules/extensions//libdri2.so

It tells libdri2 has extesion version 1.1, but your server has version 2.0, which can be seen scrolling further up:

(II) Module ABI versions:
	X.Org Server Extension : 2.0

This should be easy to fix, since it's cause by a wrong installation on your machine.

rm /opt/X11R7/lib/xorg/modules/extensions/libdri2.so
rm /opt/X11R7/lib/xorg/modules/extensions/libdri2.la

should be sufficient. And then you may rebuild libdri2.so with the correct Xserver Extension ABI. Something like:

cd my_x_server_sources
cd hw/xfree86/dri2
make install

However from what I've seen so far the xf86_video_intel master branch that you've been using isn't dependent on DRI2 at all. This would be the case if you switch to origin/dri2.

That means: As long as you are on the 2d master branch you can do even without dri2 xserver extension. You wouldn't even have to recompile it. Just deleting libdri2.so should be sufficient.

--

The second thing is that I believe you ran into
https://bugs.freedesktop.org/show_bug.cgi?id=17531

as well. Although your failure message is different.

One indication is your bisect result:

> I bisect and find when using below commit,it can work well:
> libdrm:master 738e36acbce24df0ccadb499c5cf62ccb74f56df
> xf86-video-intel:master 738e36acbce24df0ccadb499c5cf62ccb74f56df

We are talking about the exact same commit of libdrm that causes the break. It's just that you made a copy and paste mistake when posting SHA1 commit checksum of 2d driver. It's the same as libdrm, which can't be the case.

--

Last but not least I'd like to mention that I also tried running the 2d DRI2 driver branch against a DRI2 enabled Xorg Server - even in UXA mode. This fails with bug #17531 as well.

(In reply to comment #11)
> Actually I am confused by this bugreport:

Tobias, thanks for your reply.

1) Yes, this bug is not related to DRI2.

2) This bug is different with bug#17531 as this kernel doesn't have GEM. Haihao's patch should fix this bug, in a non-GEM kernel path.

Eric, please review Haihao's patch with high priority.

This patch make my xserver work again with none-GEM drm module.

Comment on attachment 18837 [details] [review]
a patch to fix the crash when using non-GEM DRM module.

looks like the patch was posted twice?

Yes.  I made a mistake. I clicked the commit button twice in a short time.

haihao's patch takes effect,we get the same result as comment #14.

With bug#17543 fixed on 2.5-branch, now 2.5-branch also blocked by this bug.

@@ -3693,7 +3692,7 @@ I830EnterVT(int scrnIndex, int flags)
 	* operation which accessing that page, like irq install, etc.
 	*/
        if (pI830->starting && !pI830->memory_manager) {
-	   if (!I830DRISetHWS(pScrn)) {
+	   if (pI830->hw_status != NULL && !I830DRISetHWS(pScrn)) {
 		   xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
 			   "Fail to setup hardware status page.\n");
 		   I830DRICloseScreen(pScrn->pScreen);

HWS_NEED_GFX(pI830) might be used for this, or put the check into I830DRISetHWS().

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

I'm the reporter of https://bugs.freedesktop.org/show_bug.cgi?id=17572 which was a duplicate of this bug. Testing the above patch (https://bugs.freedesktop.org/attachment.cgi?id=18838) makes the driver go into an endless loop when going with totally default options and crash when EXA and DRI are disabled. Stack traces etc as attachments at the duplicate bug report.

Personally I will unfortunately not be actively monitoring the G45 bugs anymore as I need to actually use my new workstation and will be putting in another graphics card. Doesn't seem to be any way to get the driver to stay alive for basic 2D work?

I pushed the bit for putting the hw_status check back in, but the moving of the other two hunks wasn't explained in a commit message in the patch, and I didn't see why they were necessary.  Could you explain?

(In reply to comment #22)
> I pushed the bit for putting the hw_status check back in, but the moving of the
> other two hunks wasn't explained in a commit message in the patch, and I didn't
> see why they were necessary.  Could you explain?
> 

This is added in commit f367334c6392a717f6cd2f4ed02200be1c6d356a.

--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -834,6 +834,11 @@ I830DRIDoMappings(ScreenPtr pScreen)
       return FALSE;
    }
 
+   if (pI830->memory_manager == NULL)
+       intel_bufmgr_fake_set_last_dispatch(pI830->bufmgr,
+                                          (volatile unsigned int *)
+                                          &sarea->last_dispatch);
+
    /* init to zero to be safe */
    sarea->front_handle = 0;
    sarea->back_handle = 0;

And I830DRIDoMappings() is called before i830_init_bufmgr(), which means pI830->bufmgr is NULL at this point. This cause NULL dereference inside intel_bufmgr_fake_set_last_dispatch().

void intel_bufmgr_fake_set_last_dispatch(dri_bufmgr *bufmgr,
                                         volatile unsigned int *last_dispatch)
{
   dri_bufmgr_fake *bufmgr_fake = (dri_bufmgr_fake *)bufmgr;

   bufmgr_fake->last_dispatch = last_dispatch;
}

Thanks for the explanation.  Applied the rest.

this issue has been blocked by bug #17621.

this issue also happens with xf86-video-intel-2.5-branch.

verified