Bug 78381

Summary: [Dell Inspiron 1525 bisected regression] Cannot resume from suspend on Ubuntu
Product: Drivers Reporter: Žygimantas Beručka (zygimantas.b)
Component: Video(DRI - Intel)Assignee: Damien Lespiau (damien.lespiau)
Status: RESOLVED CODE_FIX    
Severity: normal CC: intel-gfx-bugs, iuridiniz, johnmbryant, shacharr
Priority: P3    
Hardware: All   
OS: Linux   
Kernel Version: 3.13rc1-3.15 Subsystem:
Regression: Yes Bisected commit-id:

Description Žygimantas Beručka 2014-06-19 13:20:23 UTC
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
Comment 1 Iuri Diniz 2014-06-20 10:33:59 UTC
More completed, but it's a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=78311
Comment 2 Iuri Diniz 2014-06-20 10:44:44 UTC
*** Bug 78311 has been marked as a duplicate of this bug. ***
Comment 3 Shachar Raindel 2014-06-21 15:23:08 UTC
I can confirm the regression, as it happens on my machine as well.

Reverting the bisected commit (18442d087) fixed the issue for me. This requires some manual merge, as the revert conflicts with later code changes.

A possible revert patch is available at https://dl.dropboxusercontent.com/u/3231403/InspironBugFix/0001-Revert-drm-i915-Fix-port_clock-and-adjusted_mode.clo.patch .
Comment 4 Iuri Diniz 2014-06-21 15:40:26 UTC
Hi Shachar Raindel, 

Which version did you base your patch?
Comment 5 Iuri Diniz 2014-06-21 17:32:12 UTC
I can confirm that 3c8fb50445833b93f69b6b703a29aae3523cad0c [1] of linus/master branch (will be linux 3.16-rc2) doesn't have the bug

So, I think that 3.16-rc2 will fix this.

-------
[1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c8fb50445833b93f69b6b703a29aae3523cad0c
Comment 6 Shachar Raindel 2014-06-22 07:23:54 UTC
More specifically, commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678 [1] fixes the issue on my machine.

Can this commit be backported also to the 3.13.x stable branch? (should apply cleanly)

----
[1] - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678
Comment 7 Jani Nikula 2014-06-23 07:36:34 UTC
(In reply to Shachar Raindel from comment #6)
> More specifically, commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678 [1] fixes
> the issue on my machine.
> 
> Can this commit be backported also to the 3.13.x stable branch? (should
> apply cleanly)

The commit is tagged cc: stable. It will eventually be picked up and backported by the stable team. Expect at least a few weeks. Thanks for the report and testing.

The original bug report at fdo was:
https://bugs.freedesktop.org/show_bug.cgi?id=76520