Bug 91295 - System hangs on resume because of Intel Rapid Start Technology
Summary: System hangs on resume because of Intel Rapid Start Technology
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-10 17:04 UTC by Gabriele Mazzotta
Modified: 2017-07-24 22:46 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features: GPU hang, power/suspend-resume


Attachments
dmesg - hang on resume (120.76 KB, text/plain)
2015-07-10 17:04 UTC, Gabriele Mazzotta
no flags Details
/sys/class/drm/card0/error (263.34 KB, application/x-bzip)
2015-07-10 17:05 UTC, Gabriele Mazzotta
no flags Details

Description Gabriele Mazzotta 2015-07-10 17:04:31 UTC
Created attachment 117033 [details]
dmesg - hang on resume

My laptop supports Intel Rapid Start Technology, which is a firmware feature that makes the system suspend to disk after it has been in S3 for a while. As far as I know, the OS is not aware of this and on resume it acts as if the system had only been in S3.

This has worked flawlessly until recently. Starting from kernel v4.2 (I tested rc1 and some previous snapshots) the system hangs on resume. There are no issues if the laptop is simply suspended and the firmware doesn't make the system suspend to disk.

Here attached there's the dmesg in which there's suggested to report the issue here.

I used drm-intel-nightly (28217ad8476e98c106c3f78e06140b052e2b6b38) to get these logs.

Just a note: things are worse compared to 4.2-rc1 since X becomes usable after a while, while I had to switch to tty to get the logs with drm-intel-nightly. 

Please, tell me if you need more information.
Comment 1 Gabriele Mazzotta 2015-07-10 17:05:25 UTC
Created attachment 117034 [details]
/sys/class/drm/card0/error

Here the compressed output of /sys/class/drm/card0/error
Comment 2 Gabriele Mazzotta 2015-07-12 15:52:38 UTC
Hi,

I ran a bisection and found the culprit:

commit 149c86e74fe44dcbac5e9f8d145c5fbc5dc21261
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Apr 7 16:21:11 2015 +0100

    drm/i915: Allocate context objects from stolen

    As we never expose context objects directly to userspace, we can forgo
    allocating a first-class GEM object for them and prefer to use the
    limited resource of reserved/stolen memory for them. Note this means
    that their initial contents are undefined.

    However, a downside of using stolen objects for execlists is that we
    cannot access the physical address directly (thanks MCH!) which prevents
    their use.

    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>


I also built 4.2-rc1 with that commit reverted and everything works as expected.
Comment 3 Gabriele Mazzotta 2015-08-25 23:56:40 UTC
This issue seems to have been fixed in v4.2-rc8. Closing this.


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.