Bug 470725

This most probably is an upstream problem with the Intel graphics driver and Xorg.  I'd had related problems on my production box until I disabled DRI in the Xorg config.

We need to involve some Intel graphics developers here, if possible.

Ah, most probably libdrm is also a part of the equation.

Thanks for the report, seife. This is an interesting issue. I'll digg into this ASAP when trying to reproduce it on my Sony laptop with GM45 chipset.

Seife, could it be that you're using XAA due to EXA's bad 2D performance? It's a known issue with XAA that Xserver terminates after resume from suspend-to-ram/suspend-to-disk.

I don't think so:
seife@stoetzler:~> grep EXA /var/log/Xorg.0.log
(==) intel(0): Using EXA for acceleration
(II) EXA(0): Offscreen pixmap area of 55296000 bytes
(II) EXA(0): Driver registered support for the following operations:

Indeed you're using EXA.

Well, suspend-to-ram does not work at all for me.

# powersave -u
method return sender=:1.0 -> dest=:1.126 reply_serial=2
   int32 127
linux-kl68:~ #

Machine is 10.10.100.116

Ok. I can suspend-to-ram with 's2ram --force', but display remains black after resume. So similar or even worse issue on my Sony Vaio VGN-Z540 here.

What graphics?

GM45.

Is that reported as Intel Corporation Mobile 945GM/GMS/GME by lspci?

GM45 != 945GM. GM45 belongs to 965 family.

Has suspend to RAM ever worked on this machine?

Seife, could you add Xorg.0.log.old right after the crash occured? Thanks.

For me it's no longer readily reproducible (although I don't think that there was anything in yesterday's update to FACTORY that would have fixed it, i.e. no new kernel or X server). I'll scream as soon as it happens again.

And yes, on my machine (HP2510p) suspend to RAM always worked fine, even in the old days when we still used VBE_POST|VBE_MODE ;)

Created attachment 270606 [details]
logfile afer crash

It happened again, although a bit differently. This is what happened:
- I made sure 3d effects was enabled.
- Yesterday evening, I suspended and resumed just fine, but the machine locked up hard shortly afterwards (a few minutes). Hard reboot.
- 3D was still enabled.
- This morning, suspend to ram, resume in the office. 3D still active
- This evening, I pulled the machine out of the port replicator and wanted to suspend, but I noticed that 3D was disabled (probably by powerdevil, because I was no longer on AC power. I disabled the "disable 3D on battery" function, but powerdevil often does not really do what you tell it.
- So I wanted to enable 3D again in the KDE control panel (which was telling me "Desktop effects [X]" even though they clearly werent). So I unchecked and checked the checkbox, clicked "apply" and boom - X server locked up.
After ~5 seconds, it terminated, KDM restarted it and I was at the login screen.
Console is broken now.

I'm attaching the logfile, but there is nothing useful in it (same as last time). It is the correct logfile, as I can tell from the timestamp at the beginning.

I found this in kdm.log, at the right place (before the start of the now running X server):

Xorg: intel_bufmgr_fake.c:769: drm_intel_bufmgr_fake_contended_lock_take: Assertion `_fence_test(bufmgr_fake, block->fence)' failed.

Does this help?

I found 3 of those intel_bufmgr_fake.c messages in kdm.log and that is the number of such crashes that I remember. So it looks related. Unfortunately there are no timestamps in kdm.log :-(

In syslog, there is only:
Feb  5 21:49:42 stoetzler kernel: [82697.721807] [drm:i915_getparam] *ERROR* Unknown parameter 5
Feb  5 21:49:52 stoetzler kdm[2911]: X server for display :0 terminated unexpectedly

(In reply to comment #21)
> Xorg: intel_bufmgr_fake.c:769: drm_intel_bufmgr_fake_contended_lock_take:
> Assertion `_fence_test(bufmgr_fake, block->fence)' failed.

That's it. It's in libdrm.

(In reply to comment #22)
> In syslog, there is only:
> Feb  5 21:49:42 stoetzler kernel: [82697.721807] [drm:i915_getparam] *ERROR*
> Unknown parameter 5

Ignore this one. This way it's tested if the kernel supports GEM.

Possibly fixed with libdrm in X11:XOrg:testing project. Other packages in this project need to be installed as well if you want to verify that.

I installed libdrm-2.4.4 and rpm did not complain. So I don't think I really need other packages, right? (I did not reboot the machine yet ;)

Rebooting shouldn't be required. Ok. could be that libdrm is backward compatible to some extent.

new libdrm-2.4.4 and friends (xorg-driver-video, Mesa) did not help:

Xorg: intel_bufmgr_fake.c:769: drm_intel_bufmgr_fake_contended_lock_take: Assertion `_fence_test(bufmgr_fake, block->fence)' failed.

after returning from resume. Xorg.0.log.old again contains nothing useful.

The new libdrm / driver / Mesa combo is even worse.
Everytime I start xine, it crashes:


seife@stoetzler:~> grep Xorg.*1365: /var/log/kdm.log
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.
Xorg: intel_bufmgr_fake.c:1365: drm_intel_fake_bo_exec: Assertion `ret == 0' failed.

So I had to revert to the old libdrm-2.4.1

Kent recommends to report this issue to freedesktop also.

With the latest updates in X11:XOrg (xorg-server 1.6, xf86-video-intel 2.6.2, libdrm 2.4.5, Mesa 7.3) suspend/hibernate no longer works at all. After resume the screen remains black, you can still control the backlight, but can't switch to Linux console any longer, neither kill the Xserver with Ctrl-Alt-BS. All you can do is a cold reboot. Great stuff, this new X. This is on 945GM and openSUSE 11.1 running KDE3.

(In reply to comment #30)
> With the latest updates in X11:XOrg (xorg-server 1.6, xf86-video-intel 2.6.2,
> libdrm 2.4.5, Mesa 7.3) suspend/hibernate no longer works at all. After resume
> the screen remains black, you can still control the backlight, but can't switch
> to Linux console any longer, neither kill the Xserver with Ctrl-Alt-BS. All you
> can do is a cold reboot. Great stuff, this new X. This is on 945GM and openSUSE
> 11.1 running KDE3.

No Desktop effects, no compiz.

I've been stupid. I was using XAA. After switching back to EXA resuming from suspend/hibernate works fine again.

Is this still an issue with the latest packages from X11:XOrg buildservice project?

It doesn't seem so (although my latest update was mid of last week, after the xrandr fix, but it seems to work pretty well now). I can reopen this if it happens again.

Ok. Let's close it as fixed for now. Thanks for testing. BTW, next update might be surprising for you. empty xorg.conf should be enough for intel now. At least it's for me on 945GM.

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

*** This bug has been marked as a duplicate of bug 500994 ***

For me on openSUSE 11.1 with latest updates from X11:Xorg xserver still crashes...

This is a duplicate! Please do not reopen.

*** This bug has been marked as a duplicate of bug 500994 ***