kernel-packages team mailing list archive

[Doug Smythies <1504584@xxxxxxxxxxxxxxxxxx>]

Created attachment 118873
requested dmesg with drm.debug=14

Possibly relevant excerpt:

[  399.518389] [drm] stuck on render ring
[  399.518686] [drm] GPU HANG: ecode 6:0:0xfeffffff, reason: Ring hung, action: reset
[  399.518686] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[  399.518686] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[  399.518687] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[  399.518687] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[  399.518687] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[  399.518699] [drm:i915_reset_and_wakeup] resetting chip
[  399.518724] i915 0000:00:02.0: GEM idle failed, resume might fail
[  399.518737] pci_pm_suspend(): i915_pm_suspend+0x0/0x50 [i915] returns -11
[  399.518739] dpm_run_callback(): pci_pm_suspend+0x0/0x160 returns -11
[  399.518741] PM: Device 0000:00:02.0 failed to suspend async: error -11
[  399.518804] PM: Some devices failed to suspend, or early wake event detected

an edited /sys/class/drm/card0/error will be attached in a moment.

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