Bug 67043

Please attach your dmesg output.  Is this with dpm enabled?  Do you still have the issue without dpm enabled?  If so can you bisect?

Created attachment 82603 [details]
dmesg with dpm enabled

Created attachment 82613 [details]
dmesg from 3.10.1 kernel without the timeout issue

Tried with radeon.dpm=0 on current mainline - no difference, still got the stuck message and delayed resume. Also tried with 3.8 Ubuntu stock kernel and 3.10.1 kernel from Ubunty daily mainline builds - the issue doesn't exist on both kernels. So it matches my vague memory that it started post 3.11 - unsure if that was after dpm or some other patchset prior to that.

If it started in 3.11 can you bisect?

I suck at bisecting, but yes, I will give it a shot.

After a not-so-clean git bisect (compilation failures in vgacon.c, some TI driver I didn't need) this was the result - at least it is related to drm.

git bisect good
372835a8527f85b3eff20a18c2c339e827dfd4e4 is the first bad commit
commit 372835a8527f85b3eff20a18c2c339e827dfd4e4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Jun 15 00:13:13 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset
    
    Atm the crtc helper implementation of set_config has really
    inconsisten semantics: If just an fb update is good enough, dpms state
    will be left as-is, but if we do a full modeset we force everything to
    dpms on.
    
    This change has already been applied to the i915 modeset code in
    
    commit e3de42b68478a8c95dd27520e9adead2af9477a5
    Author: Imre Deak <imre.deak@intel.com>
    Date:   Fri May 3 19:44:07 2013 +0200
    
        drm/i915: force full modeset if the connector is in DPMS OFF mode
    
    which according to Greg KH seems to aim for a new record in most
    Bugzilla: links in a commit message.
    
    The history of this dpms forcing is pretty interesting. This patch
    here is an almost-revert of
    
    commit 811aaa55ba21ab37407018cfc01770d6b037d3fb
    Author: Keith Packard <keithp@keithp.com>
    Date:   Thu Feb 3 16:57:28 2011 -0800
    
        drm: Only set DPMS ON when actually configuring a mode
    
    which fixed the bug of trying to dpms on disabled outputs, but
    introduced the new discrepancy between an fb update only and full
    modesets. The actual introduction of this goes back to
    
    commit bf9dc102e284a5aa78c73fc9d72e11d5ccd8669f
    Author: Keith Packard <keithp@keithp.com>
    Date:   Fri Nov 26 10:45:58 2010 -0800
    
        drm: Set connector DPMS status to ON in drm_crtc_helper_set_config
    
    And if you'd dig around in the i915 driver code there's even more fun
    around forcing dpms on and losing our heads and temper of the
    resulting inconsistencies. Especially the DP re-training code had tons
    of funny stuff in it.
    
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

Verified : Reverting 372835a8527f85b3eff20a18c2c339e827dfd4e4 from HEAD does make the problem go away.

Created attachment 82700 [details] [review]
possible fix

Does the attached patch fix it?

Tested a couple times with HEAD plus patch in previous comment and it seems to have fixed the issue. Thanks!

*** Bug 66767 has been marked as a duplicate of this bug. ***

This is happening still on a Trinity 7500G

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7500G] [1002:990a]

Even with this patch

Created attachment 83581 [details]
Dmesg

This is running with the latest drm-fixes-3.11 branch with the above fix

Note that the original one and its duplicate 66767 reported in this thread happened on suspend/resume whereas this one doesn't seem to be suspend/resume related.

I was actually in a VT at the time I think when this normally happens X is up and the whole laptop appears to freeze up

I think you may be seeing a different issue that just happens to have a similar sympotom.  Please open a new bug.  This particular issue is fixed by the referenced patch.