Bug 29839 - [945GME] after resuming from hibernation cannot get X to display
Summary: [945GME] after resuming from hibernation cannot get X to display
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium critical
Assignee: Carl Worth
QA Contact: Xorg Project Team
URL: https://bugzilla.novell.com/show_bug....
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-27 05:16 UTC by Guido Berhoerster
Modified: 2010-08-27 09:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Guido Berhoerster 2010-08-27 05:16:35 UTC
I have a MSI Wind U100 with a 945GME (8086:27a6) hardware. Often, although not
always when resuming from hibernation I just see the VT8 text console
(recognizable by the "resuming from suspend..." message and a blinking cursor),
the X mouse cursor is also visible and follows mouse movements.

I can switch to other VTs and back to VT8 but cannot get X to display. The X server has *not* crashed and is alive just as all other processes started before hibernating. /var/log/Xorg.0.log, or /var/log/messages do not show anything unusual.

The problem does not occur when using the 2.9.1 driver and UMS.

This happens on openSUSE 11.3 with xf86-video-intel version 2.11.0 and xserver version 1.8.0.
Comment 1 Guido Berhoerster 2010-08-27 05:19:15 UTC
Xorg.0.log: https://bugzillafiles.novell.org/attachment.cgi?id=373212

Additional information on the hardware: https://bugzillafiles.novell.org/attachment.cgi?id=373211
Comment 2 Chris Wilson 2010-08-27 09:59:42 UTC
kernel 2.6.34-9 and -intel 2.11

Please reopen if you can reproduce this on the current kernel and driver. The most likely suspect is:

commit 985b823b919273fe1327d56d2196b4f92e5d0fae
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri Jul 2 10:04:42 2010 +1000

    drm/i915: fix hibernation since i915 self-reclaim fixes
    
    Since commit 4bdadb9785696439c6e2b3efe34aa76df1149c83 ("drm/i915:
    Selectively enable self-reclaim"), we've been passing GFP_MOVABLE to the
    i915 page allocator where we weren't before due to some over-eager
    removal of the page mapping gfp_flags games the code used to play.
    
    This caused hibernate on Intel hardware to result in a lot of memory
    corruptions on resume.  See for example
    
      http://bugzilla.kernel.org/show_bug.cgi?id=13811
    
    Reported-by: Evengi Golov (in bugzilla)
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Tested-by: M. Vefa Bicakci <bicave@superonline.com>
    Cc: stable@kernel.org
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


commit cd9f040df6ce46573760a507cb88192d05d27d86
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Jul 18 09:44:37 2010 -0700

    drm/i915: add 'reclaimable' to i915 self-reclaimable page allocations
    
    The hibernate issues that got fixed in commit 985b823b9192 ("drm/i915:
    fix hibernation since i915 self-reclaim fixes") turn out to have been
    incomplete.  Vefa Bicakci tested lots of hibernate cycles, and without
    the __GFP_RECLAIMABLE flag the system eventually fails to resume.
    
    With the flag added, Vefa can apparently hibernate forever (or until he
    gets bored running his automated scripts, whichever comes first).
    
    The reclaimable flag was there originally, and was one of the flags that
    were dropped (unintentionally) by commit 4bdadb978569 ("drm/i915:
    Selectively enable self-reclaim") that introduced all these problems,
    but I didn't want to just blindly add back all the flags in commit
    985b823b9192, and it looked like __GFP_RECLAIM wasn't necessary.  It
    clearly was.

    I still suspect that there is some subtle reason we're missing that
    causes the problems, but __GFP_RECLAIMABLE is certainly not wrong to use
    in this context, and is what the code historically used.  And we have no
    idea what the causes the corruption without it.
    
    Reported-and-tested-by: M. Vefa Bicakci <bicave@superonline.com>
    Cc: Dave Airlie <airlied@gmail.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.