Created attachment 26889 [details] Xorg log of a session during which multiple blanks occured. While doing regular work, I'm seeing complete blanks of the screen, e.g. my LCD goes totally black and enters stand-by (signal goes away completely). When I move my mouse or type some keys, the drivers seems to regain consciousness and the image re-appears after a second or 2. When I don't move at all when blanked, the screen remains blanked. The system doesn't seem to lock though, as video and/or music happily continues to play during such a blank. The blank is 100% certainly not connected with inactivity on my side. I cannot consistently reproduce the bug (happens about once an hour), but it might be that it occurs more often when watching video's and/or switching from that window to another one. This is just a feeling though, I can't pinpoint it at all. I'm using the following software: * X.Org X Server 1.6.1.901 (1.6.2 RC 1) * xf86-video-ati GIT master * 2.6.30 x86_64 * drm module from the kernel * mesa, libdrm, ati-dri, libdri and libgl from mesa GIT branch r6xx-rewrite My xorg.conf is completely default, just mentioning the essential stuff (ati device, main screen, serverlayout) and loading -ati without _any_ options.
I can confirm this behavior. Happens at least with xf86-video-ati versions 6.8 to 6.12.2, xorg server versions 1.3.0 to 1.5.3, running an r250 chip on a Thinkpad T40/T41 with 32-64 MB of vram. While driving both internal LVDS and an external DVI, and under heavy video load (easiest way to reproduce is to scroll a large window) the DVI would go blank as described. Few more facts: neither an LVDS nor an external VGA driven by the same crtc go blank (only the DVI does). Blanking only happens with hardware acceleration. It does not happen when more vram is present (tested on a T42), so it looks as if this is related to vram allocation or bandwidth problem. It does not happen on lower resolution modes, specifically when the DVI resolution does not exceed the LVDS one. Tried prioritizing video bus in several different ways, to no avail. Would be happy to provide more data upon request.
Created attachment 27360 [details] Xorg.log with fglrx. Strangely happens with fglrx too, but without providing any clear indications in the log file.
(In reply to comment #1) > I can confirm this behavior. Happens at least with xf86-video-ati versions 6.8 > to 6.12.2, xorg server versions 1.3.0 to 1.5.3, running an r250 chip on a > Thinkpad T40/T41 with 32-64 MB of vram. While driving both internal LVDS and an > external DVI, and under heavy video load (easiest way to reproduce is to scroll > a large window) the DVI would go blank as described. It's probably underflow to the crtc in your case. Digital monitors like DVI tend to be more sensitive to disruptions in the data flow. The display controllers are contending with the drawing engine for memory bandwidth. maleadt's issue is different. > > Few more facts: neither an LVDS nor an external VGA driven by the same crtc go > blank (only the DVI does). Blanking only happens with hardware acceleration. It > does not happen when more vram is present (tested on a T42), so it looks as if > this is related to vram allocation or bandwidth problem. It does not happen on > lower resolution modes, specifically when the DVI resolution does not exceed > the LVDS one. Tried prioritizing video bus in several different ways, to no > avail. A t42 with an rv350 is a faster chip with more memory bandwidth available than your rv250. Additionally, IBM only rates the DVI port on the dock to 1280x1024@60hz, while you were attempting to run a much larger mode IIRC. The underflow did not happen at lower res modes. I think you are hitting bandwidth limits of your setup so this isn't really a bug but a hardware limitation in your case.
Created attachment 27690 [details] Xserver log with fglrx. Additional information: I happen to see this bug when using fglrx too... The blanks are very similar if not identical. However lacking any technical knowledgy, I might think the issue has been introduced with 2.6.31. I'll have a look at downgrading the kernel to see whether the problem still occurs. Attached is the X log after having seen a screen blank (one or more, can't remember) using fglrx.
can you try with ati from git master? Specifically commit 66b194a78c470cb3978f310828dd96c3f3e96944.
Can you try with the latest code from xf86-video-ati git master? I just committed some new PLL code that might help.
Hi, I must say, since having switched to Fedora 12 I haven't seen these blanks anymore. Could this possibly be fixed with KMS? I'll spend some time using UMS to see if the blanks still occur. Thanks! Tim Op woensdag 09-12-2009 om 10:10 uur [tijdzone -0800], schreef bugzilla-daemon@freedesktop.org: > http://bugs.freedesktop.org/show_bug.cgi?id=22333 > > > > > > --- Comment #6 from Alex Deucher <agd5f@yahoo.com> 2009-12-09 10:10:47 PST --- > Can you try with the latest code from xf86-video-ati git master? I just > committed some new PLL code that might help. > >
appears to be fixed.
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.