Bug 66812

Summary: regression in vt-switching between x servers with ums radeon driver
Product: xorg Reporter: Andriy Gapon <avg>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED WONTFIX QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: eich
Version: 7.7 (2012.06)   
Hardware: x86-64 (AMD64)   
OS: FreeBSD   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Test patch none

Description Andriy Gapon 2013-07-11 08:30:52 UTC 
Software:
	xorg-server-1.12.4
	xf86-video-ati-6.14.6

One peculiarity of my setup is that I run two X servers.  And the regression is
exactly about that.
Until  a recent upgrade (from driver version 6.14.3) everything worked just fine.  But now if I do a direct VT-switch from one X-owned terminal to the other, then I get a significant chance of my system hanging.

I see the following things when that happens.
In Xorg.log I sometimes get (repeated many times):
(EE) RADEON(0): Timeout trying to update memory controller settings !
(EE) RADEON(0): You will probably crash now ...
In system log I sometimes see (repeated many times):
info: [drm] wait idle failed status : 0xA0003030 0x00000003
Sometimes the system just resets without leaving any clues.

Here is another interesting point.  If first I do a VT-switch to a non-graphic
(console) terminal and then to the other X terminal, then the problem never
happens.

Downgrading xf86-video-ati to 6.14.4 seems to fix the problem.
I haven't tried 6.14.5 yet.

I can do more bisecting / testing, but perhaps you would have some pointers on things that I should try first.
Comment 1 Alex Deucher 2013-07-11 12:54:03 UTC 
Bisecting would be your best bet.
Comment 2 Andriy Gapon 2013-07-19 19:45:52 UTC 
Haven't gotten around to bisecting yet.
Just a note that it happened with 6.14.4 too.
Comment 3 Andriy Gapon 2013-07-21 10:13:44 UTC 
Reverting
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?h=ums&id=eb6d769a087b2ed5952f477fc3f0b0625810a287
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ac51e331895b216d288bc7bd108a38b362214668
seems to have really fixed my problem.
Now I will try to find the guilty commit and perhaps the guilty piece of it.
Comment 4 Andriy Gapon 2013-07-21 11:08:23 UTC 
Looking at eb6d769a087b2ed5952f477fc3f0b0625810a287 it seems that it does a little bit more than the commit message says.
Whereas previously there was an early return from radeon_crtc_dpms():

if ((mode == DPMSModeOn) && radeon_crtc->enabled)
   return;

now there isn't one in radeon_*do*_crtc_dpms().

So now, when radeon_do_crtc_dpms is called RADEONRestore() it's always executed to the completion even when mode == DPMSModeOn && radeon_crtc->enabled already.

Note sure if this was intended.
Comment 5 Andriy Gapon 2013-07-21 15:59:26 UTC 
Some more data points.
Reverting only eb6d769a087b2ed5952f477fc3f0b0625810a287 still does help.
Not reverting anything and instead adding an early return from radeon_do_crtc_dpms does _not_ help.
Comment 6 Andriy Gapon 2013-07-24 12:09:38 UTC 
So, the culprit appears to be eb6d769a087b2ed5952f477fc3f0b0625810a287.
What next?
Comment 7 Alex Deucher 2013-07-24 13:21:05 UTC 
Egbert, any ideas?
Comment 8 Egbert Eich 2013-07-24 14:42:12 UTC 
Created attachment 82940 [details] [review]
Test patch

Could you please try this patch?
Comment 9 Andriy Gapon 2013-07-25 20:30:04 UTC 
Unfortunately this patch didn't help.
Comment 10 Egbert Eich 2013-07-26 15:37:18 UTC 
Could you please attach a debugger, breakpoint in RADEONRestore() and find out where  crtc->funcs->dpms points to?
Comment 11 Andriy Gapon 2014-01-22 10:09:25 UTC 
I switched to KMS driver, so I can't provide further info.

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.