Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 202756 - sys-apps/v86d: uvesafb crashes x-server when resuming from suspend to ram or disk (i915)
Summary: sys-apps/v86d: uvesafb crashes x-server when resuming from suspend to ram or ...
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Michal Januszewski (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-12-19 08:55 UTC by Roland Tapken
Modified: 2008-03-01 19:21 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Tapken 2007-12-19 08:55:55 UTC
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)
Comment 1 Doug Goldstein (RETIRED) gentoo-dev 2007-12-19 14:21:19 UTC
None of these packages are owned by "x11-drivers". This alias is apparently only for the binary drivers "ati" and "nvidia".
Comment 2 Toby Cubitt 2008-01-08 13:29:15 UTC
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.
Comment 3 Peter Weber 2008-01-13 19:56:19 UTC
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.

Comment 4 polytan 2008-01-20 23:16:41 UTC
It is the same here on i945GM...

Can I use intelfb to have 1280x800 framebuffer ?
Comment 5 Rémi Cardona gentoo-dev 2008-01-21 06:36:18 UTC
not on a laptop. Intelfb can't drive the LVDS output for laptops' LCD screens.
Comment 6 Rémi Cardona gentoo-dev 2008-02-27 12:25:42 UTC
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.
Comment 7 polytan 2008-02-27 15:32:46 UTC
(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 :/

Comment 8 Rémi Cardona gentoo-dev 2008-02-27 15:44:14 UTC
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.
Comment 9 Michal Januszewski (RETIRED) gentoo-dev 2008-03-01 19:21:14 UTC
(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.