As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

[Doug Smythies]

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 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@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@Intel.com>
    Reviewed-by: Tomas Elf <tomas.elf@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 789c630ff3f5f07238a5df1bde79187c6c1251d0 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M      drivers



_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

[Daniel Vetter]

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 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@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@Intel.com>
>     Reviewed-by: Tomas Elf <tomas.elf@intel.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> 
> :040000 040000 789c630ff3f5f07238a5df1bde79187c6c1251d0 2da3f7e20e2642d8eebd9f72528923c2ac53a8cb M      drivers
> 
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: As of kernel 4.3-rc1 system will not stay in S3 suspend [REGRESSION][BISECTED]

[Jani Nikula]

On Fri, 09 Oct 2015, Doug Smythies <dsmythies@telus.net> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel