Bug 78381

There are a number of reports[1][2][3][4][5][6] on Ubuntu's bug database about Dell Inspiron 1525 machines failing to resume from suspend on Ubuntu 14.04. The last known working kernel version is the 3.12.* series. It has been confirmed by several reporters that the bug has been introduced with 3.13rc1 and is present in later series -- at least in 3.14 and 3.15 (Ubuntu mainline kernel builds).

Ubuntu user Iuri Diniz has carried out the bisect and found the offending commit that causes this bug. Therefore I am just reposting his original report[1] and then the comment[7] about the offending commit from Launchpad.

--- CUT ---

After upgrading to Ubuntu Trusty (14.04), I cannot more resume from a previous suspend. All things were all right on 13.10.

If I boot previous kernel 3.11.0-23, everything works well.

Also I've tried these kernels:

vanilla 3.13.0-rc1 (Bugged)
vanilla 3.12.22 (Working)

I also noted if I suspend from lightdm menu (on 3.13.0-rc1), I can resume after, but If I do this after logged with my user (not root), I am unable to resume from suspend.

I cannot perform Sysrq magic keys, I can only press the power button.

--- CUT ---



His comment[7] about the offending commit is as follows:

--- CUT ---

I did a bisect and found the first bad commit:
========================
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
==================================================

So, it seems it's a upstream bug

Also, only occurs if someone is logged (in a fresh boot, if I suspend from lightdm, it resumes well). Maybe something related between some software (compiz?) and DRM layer

--- CUT ---



Should you need more information, do not hesitate to follow the relevant links, they have log files attached.


--
1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331654
2. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1315277
3. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330435
4. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1315435
5. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1310823
6. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1330043
7. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331654/comments/4