<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [Intel-gfx] As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]"
href="https://bugs.freedesktop.org/show_bug.cgi?id=92414">92414</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[Intel-gfx] As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>major
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>jairo.daniel.miramontes.caton@intel.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre><span class="quote">> This started somewhere between Kernel 4.2 and 4.3-rc1,
> but I only noticed it a day ago.
>
> The first S3 suspend after a fresh boot works fine.
> Thereafter, suspends simply resume again immediately.
>
> I get the following errors on my console:
>
> [ 152.697247] i915 0000:00:02.0: GEM idle failed, resume might fail
> [ 152.697258] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11
> [ 152.697262] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -11
> [ 152.697264] PM: Device 0000:00:02.0 failed to suspend async: error -11
> [ 152.697306] PM: Some devices failed to suspend, or early wake event detected
>
> The issue is not limited to my normal way of doing suspend, using "pm-suspend".
> It also happens using the "echo mem > /sys/power/state" method.
>
> The kernel was bisected, and the result was double checked by clean compiles
> of the first bad commit and the immediately preceding commit. Bisect results
> copied below:
>
> $ git bisect good
> dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2 is the first bad commit
> commit dc4be6071a24f0d2da6af8ce16c19f276ac4d7a2
> Author: John Harrison <John.C.Harrison at Intel.com>
> Date: Fri May 29 17:43:39 2015 +0100
>
> drm/i915: Add explicit request management to i915_gem_init_hw()
>
> Now that a single per ring loop is being done for all the different
> intialisation steps in i915_gem_init_hw(), it is possible to add proper request
> management as well. The last remaining issue is that the context enable call
> eventually ends up within *_render_state_init() and this does its own private
> _i915_add_request() call.
>
> This patch adds explicit request creation and submission to the top level loop
> and removes the add_request() from deep within the sub-functions.
>
> v2: Updated for removal of batch_obj from add_request call in previous patch.
>
> For: VIZ-5115
> Signed-off-by: John Harrison <John.C.Harrison at Intel.com>
> Reviewed-by: Tomas Elf <tomas.elf at intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> :040000 040000 789c630ff3f5f07238a5df1bde79187c6c1251d0 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M drivers</span ></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>