(In reply to Jani Nikula from comment #6) > Did you double check the bisect by running both dc4be6071a24 and > dc4be6071a24^ ?
Yes, of course, and I said so in my initial e-mail. Truth be known, this was my second bisection, as I must have made a mistake in my first attempt, because the double check failed. -- 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: Incomplete 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.harri...@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.harri...@intel.com> Reviewed-by: Tomas Elf <tomas....@intel.com> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
