kernel-packages team mailing list archive

[Bug Watch Updater <1504584@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 6 comments from the remote bug at
https://bugs.freedesktop.org/show_bug.cgi?id=92414.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2015-10-10T17:26:57+00:00 Jairo-daniel-miramontes-caton wrote:

> 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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/3

------------------------------------------------------------------------
On 2015-10-10T17:30:51+00:00 Jairo-daniel-miramontes-caton wrote:

This bug was created for tracking purposes, was reported to the intel
gfx list,  refeer to http://lists.freedesktop.org/archives/intel-
gfx/2015-October/077592.html

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/4

------------------------------------------------------------------------
On 2015-10-12T07:04:34+00:00 Daniel-ffwll wrote:

As discussed please follow up on the m-l with a link to each regression
tracking bug you create so that the links go both ways. Thanks.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/5

------------------------------------------------------------------------
On 2015-10-12T14:40:03+00:00 Jani-nikula wrote:

Please use links that contain the Message-ID so that it's easier to find
the messages in email. Please reference the original report.

Like this: http://mid.gmane.org/002301d1025d$d5765090$8062f1b0$@net

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/6

------------------------------------------------------------------------
On 2015-10-12T14:41:02+00:00 Jani-nikula wrote:

John, ideas?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/7

------------------------------------------------------------------------
On 2015-10-12T22:05:14+00:00 Doug Smythies wrote:

Additional information:

After the first resume from suspend, the processor is in a bizarre
state, where it will not go below 2.4 GHz, even though every CPU is
asking for a pstate of 16 (the minimum for my processor). This has been
tested several times, on both the preceding (good) and first bad kernels
using both methods of suspend.

My processor: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

Example (no load):

pstate being asked for:

# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16

pstate that I am getting:

# rdmsr --bitfield 15:8 -d -a 0x198
24
24
24
24
24
24
24
24

CPU freqs:

# grep MHz /proc/cpuinfo
cpu MHz : 2400.054
cpu MHz : 2399.921
cpu MHz : 2399.921
cpu MHz : 2399.921
cpu MHz : 2399.789
cpu MHz : 2399.789
cpu MHz : 2399.921
cpu MHz : 2399.921

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1504584/comments/8


** Changed in: linux
       Status: Unknown => Confirmed

** Changed in: linux
   Importance: Unknown => High

-- 
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