[RFC] X Display Failures in Suspend and Resume
Matthew Garrett
mjg59 at srcf.ucam.org
Tue Nov 11 17:18:34 UTC 2008
On Mon, Nov 10, 2008 at 07:36:31PM -0800, Jim Lieb wrote:
> On Monday 10 November 2008 17:25:24 Matthew Garrett wrote:
> > Are you sure this diagnosis is correct? The resume from hibernation case
> > is made rather more "interesting" due to usplash also being involved,
> > but the suspend to RAM case is no more inherently racy than the normal
> > VT switching case. Not having video on resume from RAM will generally be
> > down to the kernel failing to restore graphical state, something it can
> > currently only do for Intel hardware[1]. The userspace workarounds for
> > reinitialising the graphics are certainly not guaranteed to work
> > reliably.
> I've not gone into the details of the hibernation case. The issues that I
> was originally looking into was a combination of the server not resuming
> properly and some other desktop apps not resuming either because they
> got lost in a VT_WAITACTIVE. The end result is the same, races. The
> mix of suspend/resume (or hibernate/resume) into this mix just makes it
> worse.
If you resume and have unitialised graphics hardware, then there's a
reasonable chance that the X server will attempt to switch back to
graphics mode, hang and leave the VT system in VT_WAITACTIVE. The hang
there is a symptom of the problem rather than the genuine cause. If it
were possible to trigger in the general case then you'd also frequently
see it when switching the console under normal use.
> There are some scenarios that have nothing to do with suspend/resume
> that also break. F9 had similar problems switching from the boot X server
> from what I've read.
I also had some issues with usplash. It's very easy to get this wrong,
but it's possible to write apps that avoid tickling the issues.
> Thanks for your comments. Do you think the design is a) workable and
> b) worth the work to shift to it? Our goal here is to make this problem
> "go away" by cleaning up the API races.
I think the direction the kernel's going in means that VT switching will
be a pretty uncommon case in the not too distant future. I'm also pretty
sure that the problem you're seeing has VT switching issues as a
symptom, not a cause.
--
Matthew Garrett | mjg59 at srcf.ucam.org
More information about the kernel-team
mailing list