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.
Bisecting would be your best bet.
Haven't gotten around to bisecting yet. Just a note that it happened with 6.14.4 too.
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.
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.
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.
So, the culprit appears to be eb6d769a087b2ed5952f477fc3f0b0625810a287. What next?
Egbert, any ideas?
Created attachment 82940 [details] [review] Test patch Could you please try this patch?
Unfortunately this patch didn't help.
Could you please attach a debugger, breakpoint in RADEONRestore() and find out where crtc->funcs->dpms points to?
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.