| Summary: | System hangs on resume because of Intel Rapid Start Technology | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Gabriele Mazzotta <gabriele.mzt> | ||||||
| Component: | DRM/Intel | Assignee: | Chris Wilson <chris> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | gabriele.mzt, intel-gfx-bugs | ||||||
| Version: | XOrg git | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | GPU hang, power/suspend-resume | |||||||
| Attachments: |
|
||||||||
Created attachment 117034 [details]
/sys/class/drm/card0/error
Here the compressed output of /sys/class/drm/card0/error
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. 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.
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.