There are a number of reports 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 and then the comment 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 about the offending commit is as follows:
--- CUT ---
I did a bisect and found the first bad commit:
18442d08786472c63a0a80c27f92b033dffc26de is the first bad commit
Author: Ville Syrjälä <firstname.lastname@example.org>
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
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ä <email@example.com>
Reviewed-by: Jani Nikula <firstname.lastname@example.org>
Signed-off-by: Daniel Vetter <email@example.com>
: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.
More completed, but it's a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=78311
*** Bug 78311 has been marked as a duplicate of this bug. ***
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 .
Hi Shachar Raindel,
Which version did you base your patch?
I can confirm that 3c8fb50445833b93f69b6b703a29aae3523cad0c  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.
 - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3c8fb50445833b93f69b6b703a29aae3523cad0c
More specifically, commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678  fixes the issue on my machine.
Can this commit be backported also to the 3.13.x stable branch? (should apply cleanly)
 - https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678
(In reply to Shachar Raindel from comment #6)
> More specifically, commit 2b85886a5457f5c5dbcd32edbd4e6bba0f4e8678  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: