Created attachment 140371 [details] lspci Hello folks, After upgrading my distro (Ubuntu) which are using kernel 3.11.0 to kernel 3.13.0, I'm not more capable of resume after a suspend and I think it's something related to intel driver. The system resumes from a previous suspend if nobody is logged (by using click on menu option on lightdm), but if someone is logged, the system refuses to resume from a suspend. The screen goes black and sysrq magic keys doesn't work, so I have to press power button in order to get my computer back to work. I've tested these vanilla versions: 3.15 (bugged) 3.13.0-rc1 (bugged) 3.12.22 (working) After this, I just perfomed a bitsect and I found that the first bad commit is related to i915/drm This is the bisect log: -------------------------- # bad: [6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae] Linux 3.13-rc1 # good: [5e01dc7b26d9f24f39abace5da98ccbd6a5ceb52] Linux 3.12 git bisect start '6ce4eac' '5e01dc7' # good: [5cbb3d216e2041700231bcfc383ee5f8b7fc8b74] Merge branch 'akpm' (patches from Andrew Morton) git bisect good 5cbb3d216e2041700231bcfc383ee5f8b7fc8b74 # good: [e1f56c89b040134add93f686931cc266541d239a] mm: convert mm->nr_ptes to atomic_long_t git bisect good e1f56c89b040134add93f686931cc266541d239a # bad: [9073e1a804c3096eda84ee7cbf11d1f174236c75] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial git bisect bad 9073e1a804c3096eda84ee7cbf11d1f174236c75 # bad: [ab0169bb5cc4a5c86756dde662087f9d12302eb0] Merge tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect bad ab0169bb5cc4a5c86756dde662087f9d12302eb0 # bad: [3d099a05b121727bfa797391ea1da15eb33eac16] drm/i915: Add new CRC sources git bisect bad 3d099a05b121727bfa797391ea1da15eb33eac16 # bad: [f7d85c1ed1562aaab3ce10714cdd9e68013de7ae] drm/i915/vlv: reduce GT FIFO error info to a debug message git bisect bad f7d85c1ed1562aaab3ce10714cdd9e68013de7ae # bad: [46a5ae9f82719aa6e3c9c0d344772f475a335161] drm/i915: WARN is the DP aux read or write is too big git bisect bad 46a5ae9f82719aa6e3c9c0d344772f475a335161 # good: [8de123a5d89f8eaf934737758251fb18b2660231] drm/i915: Use ilk_compute_wm_level to compute WM_PIPE values git bisect good 8de123a5d89f8eaf934737758251fb18b2660231 # bad: [18442d08786472c63a0a80c27f92b033dffc26de] drm/i915: Fix port_clock and adjusted_mode.clock readout all over git bisect bad 18442d08786472c63a0a80c27f92b033dffc26de # good: [3c52f4eb9335475b7336e2d9f42cd2d41b83fc97] drm/i915: Make adjusted_mode.clock non-pixel multiplied git bisect good 3c52f4eb9335475b7336e2d9f42cd2d41b83fc97 # good: [33618ea5e0e2ccd00331fa169145894b9c5dcffe] drm/i915: Fix l3 parity user buffer offset git bisect good 33618ea5e0e2ccd00331fa169145894b9c5dcffe # good: [6878da05006feb68efe23a6ae010b1a5df32ca5f] drm/i915: Add intel_dotclock_calculate() git bisect good 6878da05006feb68efe23a6ae010b1a5df32ca5f # good: [da4a1efab8be1e373c1ad31b14deb4e422dad6cb] drm/i915: Make i9xx_crtc_clock_get() work for PCH DPLLs git bisect good da4a1efab8be1e373c1ad31b14deb4e422dad6cb # first bad commit: [18442d08786472c63a0a80c27f92b033dffc26de] drm/i915: Fix port_clock and adjusted_mode.clock readout all over -------------------------- the first bad commmit: -------------------------- 18442d08786472c63a0a80c27f92b033dffc26de is the first bad commit commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over Now that adjusted_mode.clock no longer contains the pixel_multiplier, we can kill the get_clock() callback and instead do the clock readout in get_pipe_config(). Also i9xx_crtc_clock_get() can now extract the frequency of the PCH DPLL, so use it to populate port_clock accurately for PCH encoders. For DP in port A the encoder is still responsible for filling in port_clock. The FDI adjusted_mode.clock extraction is kept in place for some extra sanity checking, but we no longer need to pretend it's also the port_clock. In the encoder get_config() functions fill out adjusted_mode.clock based on port_clock and other details such as the DP M/N values, HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then do an extra sanity check to make sure the dotclock we derived from the FDI configuratiuon matches the one we derive from port_clock. DVO doesn't exist on PCH platforms, so it doesn't need to anything but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so none of the changes apply there. v2: Use hdmi_reg color format to detect 12bpc HDMI case v3: Set adjusted_mode.clock for LVDS too v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get, eliminate the useless link_freq variable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> :040000 040000 28aa8dae70bff05e84a62d6b66eaa54e331690bd 55c4132a8c8e9088505ad5647a7b79735f5a1f54 M drivers -------------------------- I'm not the only one with this bug, there are two bugs related to this on ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331654 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331654 If any of you need more tests, you could ask me.
Someone from ubuntu devel team got my comment is placed another bug report https://bugzilla.kernel.org/show_bug.cgi?id=78381 which has more information. So marking this as duplicate *** This bug has been marked as a duplicate of bug 78381 ***
Thanks for the report and the follow-up.