Created attachment 60636 [details] [review] X server log /w acceleration enabled I am running the latest git (commit 0bda305f7ab2a4720b3fea3f318ab2a73be151e5) version of driver/xf86-video-ati. My hardware is a RV280 AGP card, for details see the attached X server log. The problem I am facing: Whenever I run the X server with acceleration enabled in the radeon driver (option 'NoAccel' set to 'off'), the screen turns black at uneven intervals, most often for ~2s, sometimes longer, then it comes up again. These events seem to happen randomly, but most often when the screen contents change, and generally at a rate high enough to make the display entirely unusable. Even typing a single character in a text window is often sufficient to trigger a blackout. I tried lots of driver option settings, such as the different AGPMode settings, disabling DRI and RenderAccel, and more, but the only thing that makes the problem disappear is to set the 'NoAccel' option to 'on' (or, for that matter, changing to the unaccelerated 'fbdev' driver). I recently switched from an older 1280x1024 flatscreen monitor to a new one with 1920x1080 resolution. The problem was already present when I still used the old monitor, but the blackouts occurred much less often, and so I got used to ignoring them. I do not remember when I first noticed the problem, nor what driver version I was running at that time. If a blackout lasts long enough, my monitor complains about video timings that are beyond its limits. As can be seen in the server logs, the preferred video mode is 1920x1080 @ 60 fps. The monitor sometimes reports a vertical frequency twice as high (120 Hz). Also, when I chvt to a text console (using a frame buffer console via the fbcon kernel module), the blackouts keep occurring even in text mode until I shut down the X server. I therefore suspect that the problem is ultimatly caused by KMS malfunctioning.
Sounds like underflow to the display controller. Also 1920x1080 is probably a bit much for the TMDS transmitter on the rv280; it's pretty close to the hw limits of the card on a number of fronts. You might need to use a mode with a lower clock. Does booting with radeon.disp_priority=2 on the kernel command line in grub help?
radeon.disp_priority=2 has no effect at all. As I wrote, the problem goes away if I disable h/w acceleration in the radeon driver, or switch to the fbdev driver. The video resolution and timing are the same in all cases. Is this consistent with the theory of the pixel clock being too high?
(In reply to comment #2) > radeon.disp_priority=2 has no effect at all. As I wrote, the problem goes away > if I disable h/w acceleration in the radeon driver, or switch to the fbdev > driver. The video resolution and timing are the same in all cases. Is this > consistent with the theory of the pixel clock being too high? It's consistent with underflow to the display controller. The memory controller on the GPU has to service several clients (displays, 3D engine, 2D engine, etc.). When you enable acceleration, the 2D and 3D engines are active and contend with the display controllers for bandwidth in the memory controller. If the memory controller not able to service the display fifo in time, it will run dry causing the blankout you see. Disabling acceleration takes the 2D and 3D engines out of contention so the memory controller only has to worry about filling display requests. A lower resolution mode will also probably help since the bandwidth requirements are lower. A 1920x1080 mode with a lower refresh rate may also help since the bandwidth requirements would also be lower (assuming your monitor will accept it).
By reducing the vertical frequency to 50 Hz, and trimming a bit off the blanking interval, I have been able to reduce the pixel clock to ~119 MHz. This greatly reduces the problem, but does not completely eliminate it. So it seems you are right, and I am closing this bug. Thank you very much for your assistance , Alex.
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.