I reported a xorg-bug for i915-driver some time ago, and it seems that this is related to uvesafb indeed (it works fine with classic vesafb). You'll find a full description including various backtraces at http://bugs.freedesktop.org/show_bug.cgi?id=10798. Summary: Start X and suspend to disk or ram. Resume and the server will crash as soon as the system tries to switch back to the X console. Reproducible: Always Steps to Reproduce: 1. start xorg 2. suspend to ram or disk 3. resume and switch back to vt7 Actual Results: Crash of xorg ("lookup error"). Expected Results: Not to crash. tuxonice-sources-2.6.23* or gentoo-souces-2.6.23* xorg-server-1.4* xf86-video-i810-2* (including current git version) VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
None of these packages are owned by "x11-drivers". This alias is apparently only for the binary drivers "ati" and "nvidia".
I'm seeing exactly the same bug, using the same setup. If I use the intelfb framebuffer device instead of uvesafb, hibernation works perfectly (I haven't tried vesafb, though I easily could if it would help). More evidence to suggest this is a uvesafb-specific problem.
This has nothing to do with X11, vesafb-tng and uvesafb seem to have the same problem since two years. I have writen spock a email last friday, but I don't get an answer till now.
It is the same here on i945GM... Can I use intelfb to have 1280x800 framebuffer ?
not on a laptop. Intelfb can't drive the LVDS output for laptops' LCD screens.
Alright, upstream says this is a uvesafb issue ... not really sure what to do here. Keeping myself as CC as I'm not entirely convinced by upstream that the Intel driver is not doing something behind uvesafb's back.
(In reply to comment #6) And so, can we have fb with suspend ? Can I use vesa and put 1024x768 at least ? (or 800x600) but not 600x480 :/
Right now, the general consensus around suspend/resume is that it doesn't mix really well with any framebuffer driver, the old vesafb being one of the least problematic and the intelfb being the ugliest of the lot. My advice is try with uvesafb, with vesafb and without any fb driver compiled in the kernel. Once you find something that works, it should be easier to find the offending code using Intel's register dumping tool. But really try without any framebuffer driver.
(In reply to comment #6) > Alright, upstream says this is a uvesafb issue ... not really sure what to do > here. > > Keeping myself as CC as I'm not entirely convinced by upstream that the Intel > driver is not doing something behind uvesafb's back. I'm going to close this as a CANTFIX. Feel free to add any information that you feel could be helpful to this bug, and I'll make sure I have a look at it. Here is what the situation looks like from my point of view. uvesafb relies entirely on the Video BIOS for all its operations. It doesn't do anything on suspend/resume. If anything does happen (framebuffer-wise) when the system is resumed, it is because a request comes from fbcon, another part of the kernel or the userspace. The fact that xorg dies after trying to switch to vt7 suggests that the Intel X driver somehow can't handle the state the video card is in before the switch. The thing is, there aren't any limitations wrt the state the card is supposed to be in before a switch back to X. Theoretically, a framebuffer driver can do whatever it wants to the video card while out of X, and it's the job of X to restore the card to a state it expects and can use. In this case, the framebuffer doesn't even control the state of the card since it only talks to the Video BIOS which then does the job for it. So why does this happen with uvesafb and not vesafb? My guess is that a video mode switch takes place after resuming the system when using uvesafb (framebuffer mode switches can't happen with vesafb) and this somehow upsets the X driver when trying to switch to vt7. If you have some time and want to play with it a little bit, you could try manually modifying the video card state after resuming and before switching back to X -- some things that might be worth checking out: - use fbset to change the video mode, - kill v86d, then use fbset to change the video mode.
