kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #147433
[Bug 1504584] Re: As of kernel 4.3-rc1 system will not stay in S3 suspend
** Bug watch added: freedesktop.org Bugzilla #90253
https://bugs.freedesktop.org/show_bug.cgi?id=90253
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1504584
Title:
As of kernel 4.3-rc1 system will not stay in S3 suspend
Status in Linux:
Confirmed
Status in linux package in Ubuntu:
Triaged
Bug description:
Note: this bug report is just for local tracking of an upstream issue:
Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-October/077592.html
also copied below:
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@xxxxxxxxx>
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@xxxxxxxxx>
Reviewed-by: Tomas Elf <tomas.elf@xxxxxxxxx>
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions
References