i810 Xv crashes after suspend -> infinite resprawn

[Paul Sladen]

X using the i810 driver on a i915MG chipset will cause a crash. The crash seems
most related use of the Xv video extension, for instance, starting up Totem
which uses it for visulisation display.

The X server then goes into an infinite loop of:

  Respawn
  Watch pointer
  Arrow pointer
  Respawn

With the background remaining black. It is not possible to get to a console and
the only way out is sysrq-s sysrq-u sysrq. On reboot, /var/log/Xorg.0.old contains:

Error in I830WaitLpRing(), now is -1274101884, start is -1274103885
pgetbl_ctl: 0x1ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: c8 head: 0 len: 1f801 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 108 instps: f0000
hwstam: fffe ier: 2 imr: 8 iir: 220
space: 130864 wanted 131064
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xe04c3000 at 0xb7940000

Fatal server error:
lockup

Error in I830WaitLpRing(), now is -1274099866, start is -1274101867
pgetbl_ctl: 0x1ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: d0 head: 0 len: 1f801 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 108 instps: f0000
hwstam: ffff ier: 0 imr: ffff iir: 220
space: 130856 wanted 131064

FatalError re-entered, aborting
lockup

A suspend-to-RAM cycle had happened at some point a couple of hours before.

[Angelo Lisco (angystardust-gmail)]

You're not alone...Same behaviour here!

OS: Linux (k)ubuntu Dapper
kernel: 2.6.15
pc: IBM Thinkpad X40
svga: Intel Corporation 82852/855GM Integrated Graphics Device
driver: i810
options: xv and dri enabled

I opened a bug at freedesktop bugzilla.
https://bugs.freedesktop.org/show_bug.cgi?id=5774

[Angelo Lisco (angystardust-gmail)]

Paul, i'm now trying the experimental driver provided by Alan Hourihane (http://www.fairlite.demon.co.uk/intel.html)...
Maybe it's too soon to say that but i think the bug is gone away: i cannot reproduce the crash anymore!

However look at this: https://bugs.freedesktop.org/show_bug.cgi?id=5774

[DanH (holmsand-gmail)]

This is maybe the same bug as #22741, that's still haunting me.

I've tried a number of the experimental drivers of Alan Hourihane's with breezy, and they have mostly been working really well (no xv-related crashes in a really long while).

[DanH (holmsand-gmail)]

In case it's gone unnoticed: I've attached a patch to bug #22741 that fixes this bug for me.

[Baishampayan Ghose (b.ghose)]

I can confirm this bug. It hit me after I did a suspend to RAM on my Toshiba Satellite Laptop. I think somebody should apply the backported patch which can be found in bug #22741

[Baishampayan Ghose (b.ghose)]

I am attaching the full crash log.

[Florian Boucault (fboucault)]

I used to have the same here (T43 1871-W34, i915GM using i810 driver).

[Jim Gettys (jg-laptop)]

I don't crash after long use.

I did crash after resume with totem, until installing Alan Horihane's driver, which has been working fine for me.

[Paul Sladen (sladen)]

This happened to me again yesterday - I suppose I should fix it and backport the necessary...

[Dave Love (fx-gnu)]

There seems to be a suggestion that this is related to
suspending, but it happens to me directly after
rebooting (on a Thinkpad X30 with current Dapper
packages).

[Florian Boucault (fboucault)]

There are two links on the xorg bugzilla, one closed (https://bugs.freedesktop.org/show_bug.cgi?id=5774) and one still opened (https://bugs.freedesktop.org/show_bug.cgi?id=4353).

Concerning the closed one, the solution might be in the comment #11 (https://bugs.freedesktop.org/show_bug.cgi?id=5774#c11).

I am still reading the full log of the opened one...

[Zack Cerza (zcerza-deactivatedaccount)]

Marking critical because of the possibility (heh, more like probability) of data loss...

As I understand it, there are fixes for this that people have tested. I haven't yet, but I'm about to. Any chance of getting this fixed before dapper releases? The i810 chips are extremely common in laptops...

[Zack Cerza (zcerza-deactivatedaccount)]

Someone even submitted a patch[0] to the duplicate bug #22741, but never got a response. :(

[0] http://librarian.launchpad.net/1619448/i810.patch

[DanH (holmsand-gmail)]

> Someone even submitted a patch[0] to the
> duplicate bug #22741, but never got a
> response.

Yeah, I did. I'm still using my patched i810 driver, and still haven't had any crashes with it.

Unfortunately, I don't know what else to do. Whining about crashing drivers here seems entirely pointless.

And who the hell is "X SWAT" anyway?

[Zack Cerza (zcerza-deactivatedaccount)]

You'd think clicking "Ubuntu X SWAT" would take you there, but it doesn't so here's their info page: https://launchpad.net/people/ubuntu-x-swat

By the way, I'm using your patch and haven't seen crashes with it yet.

[DanH (holmsand-gmail)]

So now the "SWAT team" has given up as well, and the maintainer (Daniel Stone) is nowhere to be seen.

This rather confirms my feeling that it's completely, utterly pointless to file bugs and patches in launchpad.

[Paul Sladen (sladen)]

I've been meaning to pull this out of CVS since January, thanks to Dan grabbing the base of the patch and to Zack for testing and confirming that it worked.

I've tested the patch and after some fairly harsh treatment still made the xserver freeze (but not resprawn...) but that may have been unrelated. Lets see how it goes:

xserver-xorg-driver-i810 (1:1.4.1.3-0ubuntu4) dapper; urgency=low

  * Remove duplicate dpatch entries in '00list'.

  Changes from Dan Holmsand <email address hidden>:

  * Backport of some changes from freedesktop.org CVS to fix the
    I830WaitLpRing() crashes involving Xv post suspend/hibernate.
    Attempt to close [Malone: #28326] and all its duplicates...

 -- Paul Sladen <email address hidden> Sun, 30 Apr 2006 02:51:28 +0200

(Daniels now works for a large Finnish Mobile Phone manufacturer rather than fulltime on Ubuntu).

[Angelo Lisco (angystardust-gmail)]

ok guys...i upgraded to the last driver but unfortunately bug is still there (even if now i have a different beviour): no more X crash&respawn after suspend or hibernate when i watch a video but totem (xine backend) and mplayer crash as I try to open a large video (1024x768 avi file)...

[Angelo Lisco (angystardust-gmail)]

This is mplayer log...

I think that the most relevant line is:
X11 error: BadAlloc (insufficient resources for operation)

[Angelo Lisco (angystardust-gmail)]

and that's totem log...
Same error message as the one found in mplayer log:

The error was 'BadAlloc (insufficient resources for operation)'

[Tero Karvinen (karvinen+launchpad)]

Still no picture after waking up from suspend-to-ram (s3, sleep). Can connect to computer using ssh. Screen blinks when attempting to change virtual terminals, but not even text mode works. Currently using 915resolution. Using Dapper 6.06 beta 2, just updated. Computer is Travelmate 3004WTMi.

[Tero Karvinen (karvinen+launchpad)]

Just tested without 915resolution and screen stays blank after sleep (s3) just like above.

[Nafallo Bjälevik (nafallo)]

That was the wrong button :-/.

[Angelo Lisco (angystardust-gmail)]

The fix doesn't work...reopening it

[Paul Sladen (sladen)]

Tero: you can a different issue, please can you file a bug against 'acpi-support' with the details of your laptop and 'dmidecode' output, along with an lspci -n and details of which video driver it is.

Angelo: The BadAlloc issue I think is a different one (there's another bug somewhere) and is to do with with the media player requesting a Xv drawable larger than the memory allocated to the video card (eg. it happens with the start-up image displayed on loading Xine).

Getting back to the core bug, Dan: can you confirm that the drivers at alanh's page do fix the bug; I'll try and diff out what he has in those although I'm slightly cautious because of the mention of a newer version of libshadow.

[DanH (holmsand-gmail)]

Paul: I haven't tried alanh's drivers in quite a while. They used to work fine (and fixed this particular bug in september last year), except for DRI and a stupendous amount of logging.

But testing them turned out to be a bit pointless, since the source isn't available.

Why do you ask?

[Zack Cerza (zcerza-deactivatedaccount)]

I've seen it crash at least once since using the new package. It doesn't respawn, but it does lock up hard. Pressing the power button to do a semi-graceful shutdown no longer works; I have to hold the button down until the power supply cuts off. So, it's still not totally fixed.

[Jean-Christophe Baptiste (jc-baptiste)]

I am experiencing it again too (Bug #34232).

[Paul Sladen (sladen)]

My results have been one hard-lock-up and two X-restarting to GDM login. But no infinity respawns.

...I'm not sure which is better.

[Florian Boucault (fboucault)]

I have had no crashes nor restart since a long time but it seems that the DRI is deactivated. I'll try from a live CD given that I have been playing with my installation a way too much.

[Angelo Lisco (angystardust-gmail)]

Bug #24371 as been marked as a duplicate of this bug.

[Paul Sladen (sladen)]

Since applying the separate fix for bug #29880 (Intel bridge fixups), I've not had this crash show up since; I think it is the combination of the two may have nailed it...

Please reopen this if you have the very latest Dapper and still have it.

[Valentijn Sessink (valentijn)]

linux-image-386 version 2.6.15-23 still seems to have this bug, but linux-image-686 hasn't.

[Paul Sladen (sladen)]

Valentijn: I've now fixed this to the point that I can't reproduce it on my laptop. Can you provide the exact set of steps that you are using the reproduce this now (and eg, the kernel version (as above), whether you're using 'totem-xine' or 'totem-gstreamer'.

[Valentijn Sessink (valentijn)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

(Hoping a reply by E-mail works)

At Wed, May 24, 2006 at 02:41:58PM -0000, Paul Sladen wrote:
> Valentijn: I've now fixed this to the point that I can't reproduce it
> on my laptop. Can you provide the exact set of steps that you are using

IBM R50e laptop
Ubuntu Dapper install, made up-to-date yesterday, kernel linux-image-386,
trying to suspend-to-disk. We couldn't get either one of them working, but
in the end I think the setup was as follows:

- - "nosplash" grub option
- - "ACPI_HIBERNATE" and "ACPI_SLEEP" both true
- - an extra ec_intr=0 (IIRC) option for the kernel (seen somewhere on the
Thinkwiki)

We did not need to start any programs, just a Fn-F12 (hibernate) or a Fn-F4
(sleep), then a start (either turning laptop on or waking it up) would start
the problem.

I'm sorry to tell you that the laptop itself was shipped to a customer
today, but we have another one waiting for installation and I'll try it out
next week.

In the mean time, you might just want to check a plain simple setup with a
386 kernel and see if it crashes for you. For my X40 laptop, the problem
doesn't occur anymore - even with -386 kernel.

I'll let you know if it pops up.

Kind regards,

Valentijn
- --
http://www.openoffice.nl/ Open Office - Linux Office Solutions
Valentijn Sessink <email address hidden> [phone]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFEdJpLTRf3oaxjt6kRArJxAJ4r3c3Y5CXUDC7w0Bx5tFsU9xM59gCfROiH
Ifxjssb8n8R5ycGXN4uUKVk=
=47vv
-----END PGP SIGNATURE-----

[neurol23 (neurol23)]

what helped me, was adding the boot parameter "acpi_sleep=s3_bios,s3_mode" in the grub. as far as i know in some computers only s3_bios or s3_mode is neeeded (not both)

[Paul Sladen (sladen)]

This isn't fixed, sadly. I had it once a week ago; and bug #40621 is seeing it aswell.

[Morlan Liu (morlanliu)]

Could this be related to the problem I'm having.

I just installed Dapper LTS and video playing is not very good. On Breezy it was working perfectly fine, I used Totem-xine to watch everything and Mplayer plugin for Firefox streaming.

Now Totem-xine won't open unless I right-click a file and open it with Movie Player. Also, Mplayer sometimes will display an error saying it can't open the -vo device or something.

If this is related, I hope there's a fix soon. It's driving me crazy!

[Valentijn Sessink (valentijn)]

Paul, sorry for the fuzz. I can't reproduce the issue now (while we were having a really, really bad day due to the respawn and other stupid issues with a IBM R50 laptop only 2 weeks ago). It must have been a combination of older kernels (might even have been a non upgraded kernel from an older Dapper beta). There are other sleep/resume issues, but none has to do with the infinite respawn in this bug. Sorry, again, for the confusion; as far as I'm concerned, it's fixed.

[Jean-Christophe Baptiste (jc-baptiste)]

It still remains for me. It is just in a different and at least less serious form.
Totem or any player freeze after few seconds and takes 100% of ressources.
Now, it doesn't freeze anymore the whole X server.
I can kill the application and work normally, BUT I can't read any movie, it freezes again in the same way.
And, more curiously, I get no sound anymore. For example, reading a mp3 file doesn't give anything, the player can't start reading a file and stay stack at the begining.

[Yannick (splitsch)]

Hi!
I'm using a thinkpad r50e with an uptodate Feisty.
On herd 4, suspend worked, but now, it doesn't naymore: Iwhen resuming, the screen goes block except text-box, and under firefox, the scrolling is broken.

Anyone has a workaroung ? (I've set vberestore : true in xorg.conf but it didn't work...)

Thanks

[Khalid Baheyeldin (kbahey)]

As I mentioned previously, my laptop is a Toshiba Satellite A100-TA6, using the Intel 945GM chip.

Following my test using Kubuntu Feisty Herd5 (see <a href="https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-i810/+bug/28326/comments/77">this comment above</a>), I upgraded to Feisty, hoping everything would work out.

However, after the upgrade, whenever I changed the xorg.conf file to use "i810" or "intel" (instead of "vesa"), the screen is messed up. The best way to explain the problem is to say that the font is way too big. Here is a <a href="http://baheyeldin.com/click/833/0">link to a screen shot</a>.

I also noted that the source tar.gz for the xserver-xorg-video-intel has this in the README:

"Common issues not caused by the driver
- Font sizes (DPI) are wrong. Some displays incorrectly report their
  physical size, which is harmless on most OSes that always assume 96dpi
  displays. This can be fixed through quirks for specific monitors in the X
  Server, and the output of xrandr --prop along with a physical measurement of
  the screen size in a bug report against the server can help get that fixed."

I tried setting DisplaySize 338 212 in xorg.conf Monitor section to fix the DPI, but that did not work either.

I noticed that Feisty has a new package name <a href="https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel/">xserver-xorg-video-intel</a> which replaces the older <a href="https://launchpad.net/ubuntu/+source/xserver-xorg-video-i810/">xserver-xorg-video-i810</a> (note the version numbers).

So, what I did was

a) Install xserver-xorg-video-i810 (2:1.7.4-0ubuntu1). The install of the i810 package automatically removed the -intel package.

b) Uninstall 915resolution

c) Then in /etc/default/acpi-support, I set
   POST_VIDEO=false

d) In /etc/X11/xorg.conf, I now have:

  Section "Device"
        Identifier "Intel i945"
        Driver "i810"
        Option "VBERestore" "True"
        Option "Dri" "True"
        BusID "PCI:0:2:0"
  EndSection

The good news is after I did this, I am able to:

a) Cycle through the resolutions using Ctrl-Alt-+/-
b) Send the output to the external VGA port by the Fn key combo.
c) Resuming from hibernate works well too.

The only drawback is that I am not sure if this is a sustainable solution though, since the -i810 package is replaced by the -intel package which does not work, and will be the only package in Gutsy.

[Jonathan Amir (jonathan-amir)]

I am using Kubuntu 7.04 as well, on a lenovo R60e. Last week I changed the console resolution, by adding vga=791 to the boot configuration in grub. Since then I have experienced the same behavior reported here - an infinite loop of Respawn, Watch pointer, Arrow pointer, Respawn. Removing the offending line from grub completely solved the problem for me.

Kernel: 2.6.20-15.27
pc: lenovo R60e

This is from lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

Driver: i810, dri enabled

[Felipe Navarro V. (fnavarrov)]

I agree with <a href="https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-i810/+bug/28326/comments/95">Jonathan </a>, I'm using Feisty 7.04 and i remove the line vga=791 (I'm used to use) ... Now every work : suspend + hibernate + beryl

Kernel: 2.6.20-15-generic
pc: Sony Vaio VGN-N21S/W
driver: intel, Legacy3D true
915resolution: uninstalled
This is from lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)

[Martin Rehn (minpost)]

The "vga=791" thing has no bearing on my case. I never had that option set up and this bug happens to me regularly. Dell D610 laptop here.

[Dave Gilbert (ubuntu-treblig)]

Hi,
  I've just had something that may be similar on Gutsy (Toshiba A100-306 Equium)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)

I tried to watch the penguins at:
http://200.58.119.161/pinguinos/en/pinguinos_en_vivo.html

using the totem plugin in mozilla and got a black box rather than the video, I hit the 'open in Movie Player' on the menu and X hung and eventually restarted X in a not too happy state (gnome settings daemon didn't start?); I had compiz on and the machine had previously done a hibernate (not a suspend to RAM); here is the bottom of the xorg.0.log I'm assuming all these errors came at the point it crashed?

Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x3ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 16550 head: 16544 len: 1f801 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 306 instps: f0000
hwstam: fffe ier: a2 imr: 0 iir: 200
Ring at virtual 0xe5b0c000 head 0x16544 tail 0x16550 count 3
        000164c4: 00000000
        000164c8: 02000011
        000164cc: 00000000
        000164d0: 02000011
        000164d4: 00000000
        000164d8: 02000011
        000164dc: 00000000
        000164e0: 02000011
        000164e4: 00000000
        000164e8: 02000011
        000164ec: 00000000
        000164f0: 02000011
        000164f4: 00000000
        000164f8: 02000011
        000164fc: 00000000
        00016500: 02000011
        00016504: 00000000
        00016508: 02000011
        0001650c: 00000000
        00016510: 02000011
        00016514: 00000000
        00016518: 02000011
        0001651c: 00000000
        00016520: 02000011
        00016524: 00000000
        00016528: 02000011
        0001652c: 00000000
        00016530: 02000011
        00016534: 00000000
        00016538: 02000011
        0001653c: 00000000
        00016540: 01810000
        00016544: 00000000
Ring end
space: 131052 wanted 131064
(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x2ba9e5461000

Fatal server error:
lockup

(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x3ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 16578 head: 16544 len: 1f801 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 306 instps: f0000
hwstam: fffe ier: a2 imr: 0 iir: 200
Ring at virtual 0xe5b0c000 head 0x16544 tail 0x16578 count 13
        000164c4: 00000000
        000164c8: 02000011
        000164cc: 00000000
        000164d0: 02000011
        000164d4: 00000000
        000164d8: 02000011
        000164dc: 00000000
        000164e0: 02000011
        000164e4: 00000000
        000164e8: 02000011
        000164ec: 00000000
        000164f0: 02000011
        000164f4: 00000000
        000164f8: 02000011
        000164fc: 00000000
        00016500: 02000011
        00016504: 00000000
        00016508: 02000011
        0001650c: 00000000
        00016510:...

[Smajchl (smajchl)]

I have the same problem on HP nx6110 with the same graphics card. Debian testting.

I spent lot of time to get it worgking and now I am using old version 2:1.7.2-4 with vbetool, without 3d rendering. With 3d rendering it makes this problem and with newer version, it doesn't do anything, only black screen, even if 3d rendering is off :-(

[Jesus (casiciaco)]

Hello,
I am having the same problem on my MacBook C2D 2Ghz. I am running ubuntu Gutsy ( 7.10 )
with the last kernel: 2.6.22-14-generic

When I resume from suspend, the screen gets black and the mouse freezes.
Then the screen turns off and on, the mouse responds for a few seconds and freezes again,
and so on.

The Xorg.0.log file:
------------------------

....
Synaptics Touchpad auto-dev sets device to /dev/input/event2
(**) Option "Device" "/dev/input/event2
(--) Synaptics Touchpad touchpad found
(II) Configured Mouse: ps2EnableDataReporting: succeeded
Error in I830WaitLpRing(), now is -950203834, start is -950205835
pgetbl_ctl: 0x7ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: a303030
LP ring tail: e8 head: 0 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc1 instpm: 0
memmode: 306 instps: 2014ca
hwstam: fffe ier: a2 imr: 0 iir: 10
space: 130832 wanted 131064
(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xf8ac1000 at 0xb79c9000

Fatal server error:
lockup

(II) AIGLX: Suspending AIGLX clients for VT switch
Error in I830WaitLpRing(), now is -950201826, start is -950203827
pgetbl_ctl: 0x7ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: a303030
LP ring tail: f0 head: 0 len: 1f001 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc1 instpm: 0
memmode: 306 instps: 2014ca
hwstam: fffe ier: a2 imr: 0 iir: 10
space: 130824 wanted 131064

FatalError re-entered, aborting
lockup
--------------------------------------------

Any suggestion?

[unggnu (unggnu)]

Could you please recheck it with Gutsy Final Live CD? In Gutsy i810 driver is deprecated and intel driver is used instead.

[Khalid Baheyeldin (kbahey)]

I reported this above in comment 62 last year on a Toshiba A100-TA6.

I tried the Gutsy live CD. It allows suspend, but not hibernate.

When I tried suspend, the video was fine after and the desktop appeared again unharmed.

So, I can say that Gutsy fixed it with suspend. Unsure about hibernate, but it probably is the same.

I am tempted to upgrade to Gutsy and see what happens.

[Khalid Baheyeldin (kbahey)]

The first sentence I posted above may be confusing.

I had the problem initially on Edgy. When I upgraded to Feisty, I installed an alternative driver, and it works fine. See comment 94.

Now with Gutsy, there seems to be solution, based on the live CD test in my comment above this one. I will confirm it when I upgrade to Gutsy soon.

[unggnu (unggnu)]

I am closing this bug because it seems to be fixed. Feel free to open it again if the issue still happens with Gutsy Gibbon and the new Intel driver.

@Khalid Baheyeldin
Hibernate couldn't work with Live CD since everything is stored only in Memory.

[Jesus (casiciaco)]

The intel driver also crashes. It seems to be a problem related to the last
kernel update.
Actually, in the following link it is recommended to downgrade to kernel
2.6.22-12-generic:

https://help.ubuntu.com/community/MacBook

Now, suspend works properly.

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=12642)
Xorg-log after crash

Same problem here, tested with

- Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller
- Gentoo system
- xorg-server-1.4-r2
- xf86-video-i810 2.1.0, 2.1.1, 2.1.99 and current git version
- kernel 2.6.22 and 2.6.23
- with framebuffer (vesa, uvesa) and without

Steps to reproduce:
1. Boot system (drm and i915 unloaded)
2. Start X (everything's ok)
3. Use xterm or switch back to VT
4. s2ram
5. Resume
X will crash as soon it is activated.

It does not matter if you exit X and unload drm and i915 before suspending! X will crash when you try to restart it after resume.

Other way to reproduce:
1. Start system (without X)
2. s2ram
3. resume
4. Start X -> everything is OK
5. Quit X
6. s2ram
7. resume
8. Start X -> Crash

So I don't think this might be a kernel problem.

Interesting line from the logfile:
> space: 130800 wanted 131064

This value varies from time to time, so it seems to be a memory allocation problem?

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=12643)
my current xorg.conf

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=12644)
current kernel config

[Freedesktop-tmp (freedesktop-tmp)]

X doesn't crash when setting option "NoAccel" to true. But... no dri, no compiz and very slow window redraw (e.g. when moving windows). Just a temporary solution for me.

This bug might be related to bug #11720.

[Jesse Barnes (jbarnes-virtuousgeek)]

Sounds like an intel driver bug.

[Jesse Barnes (jbarnes-virtuousgeek)]

Upping severity as this causes a crash/hang.

[Jesse Barnes (jbarnes-virtuousgeek)]

Have you tested with the latest git driver? We fixed several suspend/resume bugs (really Enter/LeaveVT bugs) for that release, hopefully yours was fixed as well.

Could also be related to 11432 or 13196.

It would be helpful if you could build the intel_reg_dumper tool and capture some register state from after the resume before the X crash along with a dump from before starting a working X session.

[Jesse Barnes (jbarnes-virtuousgeek)]

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

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13040)
Log the crashed server with current git tree

I've just compiled and tested the current git version. The server still crashes (same procedure as described earlier or in bug #11720), but now it looks somewhat different. I'll doing additional tests tomorrow.

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13068)
Backtrace when X crashed after resume and vt-switch

New backtrace with current git version of xf86-video-intel

1. Start system w/o X
2. Start X with gdb (ssh)
3. Switch to vt1 and suspend
4. Resume and switch back to vt7 -> crash

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13069)
intel_reg_dump after startup but before X

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13070)
intel_reg_dump after startup while X is running

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13071)
intel_reg_dump after resume but before switching to vt7

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13072)
intel_reg_dump after resume and switch to vt7 (this means, after crash)

[Freedesktop-tmp (freedesktop-tmp)]

If you require additional info, let me suggest to give you temporary root-access to my system so you can trace this bug by yourself. Please contact me by mail.

[Freedesktop-tmp (freedesktop-tmp)]

Created an attachment (id=13115)
Xorg.log when crashing after resuming from disk (tuxonice)

I just did some tests with tuxonice instead of default suspend. When resuming from disk, the server keeps crashing when entering vt7. But it seems to be slightly different because I was not able to backtrace this crash with gdb. The screen shows garbage but the server still runs and receives SIGUSR1-events (however it does not handle them).

Maybe an interesting detail: When suspending to mem via sysfs (using hibernate-tools) after killing a running X-session, the screen is blank after resuming. If I'm not totally wrong even the backlight keeps disabled. But when starting X (using an ssh-connection) the backlight is enabled again and the server crashes the same way it did when suspending to disk.

None of this problems occurs when option NoAccel is true in xorg.conf.

Is someone working on this? I will help as best as I can, but this bug is really annoying.

[Jesse Barnes (jbarnes-virtuousgeek)]

I wonder if this might be related to 13196... my latest theory there is that we're not letting the PLLs settle for a long enough period before writing the pipe registers... There's a patch there to test that theory, can you give it a try?

[Freedesktop-tmp (freedesktop-tmp)]

Thanks to Jesse, I was able to find out more information about the problem. To make it short, resuming works fine with classic vesafb, although I'm not sure wether it had worked all the time. Actually, it seems that I experienced different problems, all related to the kernel:

The first one (which encouraged me to start experimenting with various versions and kernel settings), resuming from disk with vesafb-tng (kernel 2.6.22), was apparently fixed some times ago and works at least with current git drivers.

The second one, resuming from ram with vesafb-tng, still exists but is a kernel problem (the screen stays black and the system completely hangs on resume, independently of starting an X-session).

The third and current one (used for the backtraces) occurs with the new uvesafb and kernel 2.6.23, but I think it may be an uvesafb-bug so I'll report it there, too.

I stupidly never tested with classic vesafb or without fb-support because I thought the driver is disabled when omitting the video=-line from kernel options, but obviously I was wrong.

@Jesse: Thank you for your patience, and sorry for the missleading and imperfect description of the bug. At least I learned how to use git and how to get backtraces with gdb ;-). Please change status if you think that this bug doesn't belong to xorg any longer.

[Freedesktop-tmp (freedesktop-tmp)]

Added the bug to gentoo database:
http://bugs.gentoo.org/show_bug.cgi?id=202756

[Michael Fu (michael-fu-intel)]

(In reply to comment #19)
>
> @Jesse: Thank you for your patience, and sorry for the missleading and
> imperfect description of the bug. At least I learned how to use git and how to
> get backtraces with gdb ;-). Please change status if you think that this bug
> doesn't belong to xorg any longer.
>

Roland, did you have a chance to try the patch in bug# 13196 that Jesse mentioned?

[Freedesktop-tmp (freedesktop-tmp)]

I tried already, it had no effect. At the moment I'm pretty sure that this is an uvesafb-issue because my system resumes perfectly since I'm using classic vesafb. Futhermore there is another user with the same problem at gentoo's bugzilla.

[Benjamin-close (benjamin-close)]

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

[Michael Fu (michael-fu-intel)]

(In reply to comment #19)
>
> I stupidly never tested with classic vesafb or without fb-support because I
> thought the driver is disabled when omitting the video=-line from kernel
> options, but obviously I was wrong.
>

Roland, it sounds to me if you remove vesafb kernel driver, just using drm driver, the suspend/resume works fine then?

[Priit Laes (plaes)]

(In reply to comment #24)
> (In reply to comment #19)
> >
> > I stupidly never tested with classic vesafb or without fb-support because I
> > thought the driver is disabled when omitting the video=-line from kernel
> > options, but obviously I was wrong.
> >
>
> Roland, it sounds to me if you remove vesafb kernel driver, just using drm
> driver, the suspend/resume works fine then?
>

Withouth uvesafb compiled in kernel, suspend-resume works fine for me.

[Michael Fu (michael-fu-intel)]

(In reply to comment #25)
> (In reply to comment #24)
> > (In reply to comment #19)
> > >
> > > I stupidly never tested with classic vesafb or without fb-support because I
> > > thought the driver is disabled when omitting the video=-line from kernel
> > > options, but obviously I was wrong.
> > >
> >
> > Roland, it sounds to me if you remove vesafb kernel driver, just using drm
> > driver, the suspend/resume works fine then?
> >
>
> Withouth uvesafb compiled in kernel, suspend-resume works fine for me.
>

great. I'm closing this bug then..

[Julien Olivier (julo)]

This bug is back in Lucid.

[Timo Aaltonen (tjaalton)]

don't reopen ancient bugs, file new ones instead.