← Back to team overview

kernel-packages team mailing list archive

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

 

$ uname -a
Linux d0rje 4.4.0-12-generic #28-Ubuntu SMP Wed Mar 9 00:33:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

9 16:19:58 d0rje kernel: [46297.093984] ------------[ cut here ]------------
Mar  9 16:19:58 d0rje kernel: [46297.094018] WARNING: CPU: 0 PID: 0 at /build/linux-H9bHY_/linux-4.4.0/drivers/gpu/drm/i915/intel_display.c:11386 intel_check_page_flip+0xfb/0x110 [i915]()
Mar  9 16:19:58 d0rje kernel: [46297.094020] Kicking stuck page flip: queued at 2785183, now 2785187
Mar  9 16:19:58 d0rje kernel: [46297.094021] Modules linked in: bnep drbg ansi_cprng ctr ccm bluetooth uvcvideo arc4 videobuf2_vmalloc iwldvm intel_rapl videobuf2_memops snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic videobuf2_v4l2 videobuf2_core x86_pkg_temp_thermal v4l2_common intel_powerclamp snd_hda_intel snd_hda_codec videodev mac80211 snd_hda_core media coretemp snd_hwdep kvm_intel kvm snd_pcm snd_seq_midi irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi_event snd_rawmidi iwlwifi snd_seq snd_seq_device snd_timer asus_nb_wmi asus_wmi mxm_wmi sparse_keymap cfg80211 aesni_intel snd aes_x86_64 lrw soundcore mei_me gf128mul mei glue_helper shpchp ablk_helper lpc_ich cryptd joydev input_leds mac_hid wmi serio_raw ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_limit xt_tcpudp xt_addrtype nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack bbswitch(OE) ip6table_filter ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack parport_pc ppdev iptable_filter ip_tables x_tables lp parport autofs4 hid_generic usbhid hid i915 psmouse i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci atl1c video fjes
Mar  9 16:19:58 d0rje kernel: [46297.094075] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           OE   4.4.0-11-generic #26-Ubuntu
Mar  9 16:19:58 d0rje kernel: [46297.094076] Hardware name: ASUSTeK Computer Inc. K53SD/K53SD, BIOS K53SD.205 03/06/2012
Mar  9 16:19:58 d0rje kernel: [46297.094077]  0000000000000086 edf7387dbd188491 ffff880246c03d60 ffffffff813e1ec3
Mar  9 16:19:58 d0rje kernel: [46297.094079]  ffff880246c03da8 ffffffffc029da50 ffff880246c03d98 ffffffff8107fe12
Mar  9 16:19:58 d0rje kernel: [46297.094081]  ffff88024564a000 ffff880240fb5000 ffff88024564a1a8 0000000000000000
Mar  9 16:19:58 d0rje kernel: [46297.094083] Call Trace:
Mar  9 16:19:58 d0rje kernel: [46297.094084]  <IRQ>  [<ffffffff813e1ec3>] dump_stack+0x63/0x90
Mar  9 16:19:58 d0rje kernel: [46297.094091]  [<ffffffff8107fe12>] warn_slowpath_common+0x82/0xc0
Mar  9 16:19:58 d0rje kernel: [46297.094093]  [<ffffffff8107feac>] warn_slowpath_fmt+0x5c/0x80
Mar  9 16:19:58 d0rje kernel: [46297.094110]  [<ffffffffc0227d5e>] ? __intel_pageflip_stall_check+0xfe/0x110 [i915]
Mar  9 16:19:58 d0rje kernel: [46297.094126]  [<ffffffffc02408fb>] intel_check_page_flip+0xfb/0x110 [i915]
Mar  9 16:19:58 d0rje kernel: [46297.094138]  [<ffffffffc01c634b>] ironlake_irq_handler+0x3db/0xc30 [i915]
Mar  9 16:19:58 d0rje kernel: [46297.094141]  [<ffffffff813ead49>] ? timerqueue_add+0x59/0xb0
Mar  9 16:19:58 d0rje kernel: [46297.094143]  [<ffffffff810ed95d>] ? enqueue_hrtimer+0x3d/0x90
Mar  9 16:19:58 d0rje kernel: [46297.094145]  [<ffffffff810d979d>] handle_irq_event_percpu+0x8d/0x1d0
Mar  9 16:19:58 d0rje kernel: [46297.094146]  [<ffffffff810d991e>] handle_irq_event+0x3e/0x60
Mar  9 16:19:58 d0rje kernel: [46297.094148]  [<ffffffff810dce5d>] handle_edge_irq+0x7d/0x150
Mar  9 16:19:58 d0rje kernel: [46297.094150]  [<ffffffff8101a15a>] handle_irq+0x1a/0x30
Mar  9 16:19:58 d0rje kernel: [46297.094152]  [<ffffffff8181f21b>] do_IRQ+0x4b/0xd0
Mar  9 16:19:58 d0rje kernel: [46297.094155]  [<ffffffff8181d302>] common_interrupt+0x82/0x82
Mar  9 16:19:58 d0rje kernel: [46297.094155]  <EOI>  [<ffffffff816b3e5e>] ? cpuidle_enter_state+0x10e/0x2b0
Mar  9 16:19:58 d0rje kernel: [46297.094161]  [<ffffffff816b3e4f>] ? cpuidle_enter_state+0xff/0x2b0
Mar  9 16:19:58 d0rje kernel: [46297.094163]  [<ffffffff816b4037>] cpuidle_enter+0x17/0x20
Mar  9 16:19:58 d0rje kernel: [46297.094165]  [<ffffffff810c2bf2>] call_cpuidle+0x32/0x60
Mar  9 16:19:58 d0rje kernel: [46297.094167]  [<ffffffff816b4013>] ? cpuidle_select+0x13/0x20
Mar  9 16:19:58 d0rje kernel: [46297.094169]  [<ffffffff810c2eb0>] cpu_startup_entry+0x290/0x350
Mar  9 16:19:58 d0rje kernel: [46297.094171]  [<ffffffff8181028c>] rest_init+0x7c/0x80
Mar  9 16:19:58 d0rje kernel: [46297.094174]  [<ffffffff81f59011>] start_kernel+0x481/0x4a2
Mar  9 16:19:58 d0rje kernel: [46297.094176]  [<ffffffff81f58120>] ? early_idt_handler_array+0x120/0x120
Mar  9 16:19:58 d0rje kernel: [46297.094177]  [<ffffffff81f58339>] x86_64_start_reservations+0x2a/0x2c
Mar  9 16:19:58 d0rje kernel: [46297.094179]  [<ffffffff81f58485>] x86_64_start_kernel+0x14a/0x16d
Mar  9 16:19:58 d0rje kernel: [46297.094180] ---[ end trace 4a0e7fcdc4696f00 ]---


The first S3 suspend after a fresh boot works fine. I get the following errors on my console:

[ 1942.079202] [drm] stuck on render ring
[ 1942.079591] [drm] GPU HANG: ecode 6:0:0xf288fff9, in Xorg [1053], reason: Ring hung, action: reset
[ 1942.079592] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[ 1942.079593] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[ 1942.079594] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[ 1942.079595] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[ 1942.079595] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[ 1942.081686] drm/i915: Resetting chip after gpu hang
[ 1948.079272] [drm] stuck on render ring
[ 1948.079681] [drm] GPU HANG: ecode 6:0:0xf288fff9, in Xorg [1053], reason: Ring hung, action: reset
[ 1948.079773] [drm:i915_set_reset_status [i915]] *ERROR* gpu hanging too fast, banning!
[ 1948.081815] drm/i915: Resetting chip after gpu hang
[ 1962.086330] [drm] stuck on render ring
[ 1962.086720] [drm] GPU HANG: ecode 6:0:0xfeffffff, reason: Ring hung, action: reset
[ 1962.088826] drm/i915: Resetting chip after gpu hang
[ 1968.089357] [drm] stuck on render ring
[ 1968.089744] [drm] GPU HANG: ecode 6:0:0xfeffffff, reason: Ring hung, action: reset
[ 1968.091850] drm/i915: Resetting chip after gpu hang

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


References