kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #166804
[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