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.harri...@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.harri...@intel.com> Reviewed-by: Tomas Elf <tomas....@intel.com> Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1504584/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
