[Bug 78381] New: [Dell Inspiron 1525] Cannot resume from suspend on Ubuntu

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=78381

            Bug ID: 78381
           Summary: [Dell Inspiron 1525] Cannot resume from suspend on
                    Ubuntu
           Product: Drivers
           Version: 2.5
    Kernel Version: 3.13rc1-3.15
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - Intel)
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: zygimantas.b at gmail.com
                CC: intel-gfx-bugs at lists.freedesktop.org
        Regression: No

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 at 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 at linux.intel.com>
    Reviewed-by: Jani Nikula <jani.nikula at intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter at 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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.