Bug 97392 - blank/dpms off causes X freezing on Redwood with commit 9090309e057dc703d1a5bffd88e6cae14108cfc3
Summary: blank/dpms off causes X freezing on Redwood with commit 9090309e057dc703d1a5b...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-18 11:55 UTC by mkgmafbt
Modified: 2016-08-26 08:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
Xorg log after terminating X (40.34 KB, text/plain)
2016-08-18 11:55 UTC, mkgmafbt 		no flags Details
X bt (2.77 KB, text/plain)
2016-08-19 10:30 UTC, mkgmafbt 		no flags Details
Add some debugging output (5.13 KB, patch)
2016-08-24 08:28 UTC, Michel Dänzer 		no flags Details | Splinter Review
X log with patch applied (284.62 KB, text/plain)
2016-08-24 09:53 UTC, mkgmafbt 		no flags Details
Call drmmode_clear_pending_flip first in drmmode_flip_handler/abort (1.83 KB, patch)
2016-08-24 13:55 UTC, Michel Dänzer 		no flags Details | Splinter Review
Show Obsolete (1) View All

Description mkgmafbt 2016-08-18 11:55:12 UTC 
Created attachment 125872 [details]
Xorg log after terminating X

blank/dpms off causes X freezing. Freezing in this case means no unblanking, keyboard and mouse not working. (dead lock while unblanking?)
When I kill X via ssh, the two displays unblank and I can start X just fine. 

I did a git bisect and commit 9090309e057dc703d1a5bffd88e6cae14108cfc3 "Wait for pending flips to complete before turning off an output or CRTC" causes the issue here.

AMD Redwood aka HD5670 (retail), Linux 4.7.x, amd64, mesa and libdrm git, llvm svn
Comment 1 Michel Dänzer 2016-08-19 01:53:24 UTC 
(In reply to mkgmafbt from comment #0)
> blank/dpms off causes X freezing.

Does it matter how DPMS off is entered (timeout, locking the display, xset dpms force off, ...), or does it happen in all cases? Which desktop environment are you using?


> Freezing in this case means no unblanking, keyboard and mouse not working. 

Can you attach gdb to Xorg and get a backtrace when it's in this state?
Comment 2 mkgmafbt 2016-08-19 10:28:04 UTC 
(In reply to Michel Dänzer from comment #1)
> (In reply to mkgmafbt from comment #0)
> > blank/dpms off causes X freezing.
> 
> Does it matter how DPMS off is entered (timeout, locking the display, xset
> dpms force off, ...), or does it happen in all cases? Which desktop
> environment are you using?

I haven't tested locking, but it doesn't make a difference if it times out or I use xset. I'm using lxqt (openbox+compton by default)
What makes a different is how I end X. If I kill X and start X unblanking/dpms on usually works, if I end X (log out) and start x, the displays doesn't wake up after dpms off.

> 
> > Freezing in this case means no unblanking, keyboard and mouse not working. 
> 
> Can you attach gdb to Xorg and get a backtrace when it's in this state?

I strip debugging symbols on this machine, but I can rebuild stuff if needed. I did rebuild X, libdrm and ddx, do you need something else too?
Comment 3 mkgmafbt 2016-08-19 10:30:34 UTC 
Created attachment 125908 [details]
X bt
Comment 4 mkgmafbt 2016-08-19 11:14:58 UTC 
(In reply to mkgmafbt from comment #2)
> What makes a different is how I end X. If I kill X and start X
> unblanking/dpms on usually works, if I end X (log out) and start x, the
> displays doesn't wake up after dpms off.
Well after a coffee break X hang too, so the only difference seems to be time...
Comment 5 Michel Dänzer 2016-08-24 08:28:14 UTC 
Created attachment 125991 [details] [review]
Add some debugging output

Please reproduce the problem with this patch applied and then attach the corresponding log file. Note that this will generate a lot of debugging output, so the faster you can reproduce, the better. :)
Comment 6 mkgmafbt 2016-08-24 09:53:26 UTC 
Created attachment 125997 [details]
X log with patch applied

Here it is. I didn't force dpms off, just let it time out.
Comment 7 Michel Dänzer 2016-08-24 13:55:19 UTC 
Created attachment 126005 [details] [review]
Call drmmode_clear_pending_flip first in  drmmode_flip_handler/abort

This patch should fix the problem, please test.
Comment 8 mkgmafbt 2016-08-24 18:38:56 UTC 
Yes works. Thanks
Comment 9 Michel Dänzer 2016-08-25 06:32:31 UTC 
Excellent, thanks for testing, but bug reports should only be resolved when the fix has landed in Git.
Comment 10 Michel Dänzer 2016-08-26 08:32:51 UTC 
Ended up landing a slightly different fix:

commit a36fdaff40d5b4795a1400c348a80eee94892212
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Aug 24 22:52:11 2016 +0900

    Don't override crtc parameter value in drmmode_flip_handler/abort

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.