As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]
On Fri, 09 Oct 2015, Doug Smythies wrote: > This started somewhere between Kernel 4.2 and 4.3-rc1, > but I only noticed it a day ago. Thanks for the report, please let's follow up at [1]. Thanks, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=92414 -- Jani Nikula, Intel Open Source Technology Center
As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]
Another regression for Jairo to track. -Daniel On Thu, Oct 08, 2015 at 11:43:39PM -0700, Doug Smythies wrote: > > Hi, > > 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 :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 :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 > 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 > Reviewed-by: Tomas Elf > Signed-off-by: Daniel Vetter > > :04 04 789c630ff3f5f07238a5df1bde79187c6c1251d0 > 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M drivers > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]
Hi, 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 :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 :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 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 Reviewed-by: Tomas Elf Signed-off-by: Daniel Vetter :04 04 789c630ff3f5f07238a5df1bde79187c6c1251d0 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M drivers
