After running a game through wine, some graphic elements of other applications get garbled. These include window decorations, window shadows, images in already opened tabs of firefox, parts of the taskbar etc. They usually return to normal if refreshed (e.g. window shadows on resizing the window). The problem seems to occur only through wine, but I don't think its wine's fault. I use 32bit debian unstable (kde 4.4.5, compiz 8.4, xserver 7.6 (xserver-xorg-core 1.9.5)) with vanilla kernel 2.6.37.6 and wine 1.3.15 from sources. The issue appears with both the installed mesa 7.10.2 and 7.11-dev from git. I'm not sure about the product and component, just guessing... #35452 might be related, but there Michel Dänzer said that's related to page flipping, which is not in 2.6.37, and this one also happens with non-fullscreen games.
Please attach the full Xorg.0.log and the output of dmesg and glxinfo. This is probably a driver issue.
Created attachment 46675 [details] Xorg.0.log
Created attachment 46676 [details] dmesg
Created attachment 46677 [details] glxinfo
Now I have seen this corruption without running anything through wine.
I observed that this corruption is often accompanied by these messages on the console from which I start a game: radeon: mmap failed, errno: 1 Mesa: User error: GL_OUT_OF_MEMORY in glTexImage radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 radeon: mmap failed, errno: 1 Some of the corruption disappears after a suspend-resume cycle. Can this be a memory-accounting bug? A possibly unrelated question: what happens if the scene to be rendered needs more than VRAM+GART amount of data?
(In reply to comment #6) > I observed that this corruption is often accompanied by these messages on the > console from which I start a game: What exactly does 'often' mean? If it's not always, it probably can't (fully) explain the problem... > radeon: mmap failed, errno: 1 > Mesa: User error: GL_OUT_OF_MEMORY in glTexImage Looks like this app ran out of memory. (errno: 1 means EPERM, not sure how that can happen...) > A possibly unrelated question: what happens if the scene to be rendered needs > more than VRAM+GART amount of data? It's up to the userspace drivers to split it up into smaller chunks that can fit. A couple of random things to try would be radeon.agpmode=4 and =-1, disabling tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't hurt either.
(In reply to comment #7) > (In reply to comment #6) > > I observed that this corruption is often accompanied by these messages on the > > console from which I start a game: > > What exactly does 'often' mean? If it's not always, it probably can't (fully) > explain the problem... Well, 'sometimes' might have been a better word. I don't think it explains the problem either, just mentioned it for completeness' sake. > A couple of random things to try would be radeon.agpmode=4 and =-1, disabling > tiling, ... Trying a newer kernel and possibly r300g driver probably wouldn't > hurt either. Now I'm using kernel 3.0, compiz runs on mesa 7.10.3, and I start games with mesa from git. The problem still exists. The interesting thing is that palettes also seem to be changing: the border lines of areas in Qt windows change their colors (mostly into purple or green), the names in the chat window change colors in kopete, and the colors in gnome-terminal become different (all text become the same color).
Created attachment 50722 [details] corrupted image in firefox Now I found a good example of this corruption. When Firefox displays a large image it is frequently filled with garbage, and due to the size of the image, it is clearly visible that the garbage is the remnants of previously displayed images. I think the newly created surfaces in texture-from-pixmap operations are not flushed properly. Or something like that. In the attachment http://static.szanalmas.hu/postpix/71876_1.jpg should be shown (don't worry it doesn't make any sense even in Hungarian). The startled Misato is the actual desktop background (with the folderview plasmoid in the upper left corner), the '1' in the green circle is a frame from a recently played youtube video, and some of the other garbage are also identifiable. After a few tab switches this image got clear, but doing a back-forward on that tab made it filled with different garbage. I think redrawing the image clears it, and a realloc leaves it uninitialized again.
(In reply to comment #7) > A couple of random things to try would be radeon.agpmode=4 and =-1, disabling > tiling, ... Have you tried any of these?
(In reply to comment #10) > (In reply to comment #7) > > A couple of random things to try would be radeon.agpmode=4 and =-1, disabling > > tiling, ... > > Have you tried any of these? Now I tried radeon.agpmode=-1 for a couple of days, but this issue didn't appear. I could only reproduce the corruption of the image mentioned in comment 9. Usually it takes several days of uptime for the corruption to start to appear noticeably, so the experiment might have been too short. I'll try it again later.
radeon.agpmode=-1 stops the corruption I was getting after scrolling a PDF file in okular with a radeon 9600xt. The problem with this solution is that frequently Xorg freezes for several minutes. Also, I don't think that the AGP bridge is at fault here, since an nvidia card works fine.
Apparently, there are two kinds of corruption in my case. The first one is triggered by display of large pixmaps or textures, and manifests itself with corruption of fonts, menus, decorations, icons and widgets all over the screen. It is easy to trigger this by scrolling quickly through a PDF file in okular, or after running Google earth or a game. After some tests for several hours, it appears that the cause is the Virtualbox kernel modules. In fact, after removing them, I haven't been able to trigger this type of corruption again. The second one is the one manifested in Firefox with large pixmaps, described in comment 9. If I open that image in Firefox and magnify it to 1:1, then it appears black. Returning to the original magnification makes it appear partly corrupted with the contents of other windows (I'm using kwin with compositing). Opening and zooming the same image in Chrome does not exhibit the corruption. I haven't found a way to resolve this yet.
I spoke too soon: minor, transient corruption still occurs. For example, for some seconds the glyph "u" would disappear from the panel and some widgets became corrupted. After a while, everything returned to normal. Maybe the virtualbox kernel modules were causing further corruption that started elsewhere?
Since I upgraded to mesa 7.11 I experience significantly less corruption than with 7.10. It still happens sometimes, though. Now I removed the virtualbox modules to give it a try. Meanwhile, I also tried to reproduce the firefox image corruption in a vnc screen, and it didn't happen, while running firefox normally is still bad. I think it means this is not a bug in firefox, but in xorg/mesa/libdrm/linux somewhere.
The type of minor, transient corruption described in comment 14 is this: some glyphs or stripes of a widget become transparent for some seconds or minutes. This is unlike the original corruption, which would garble the display, rendering X unusable.
I'm afraid the virtualbox modules have nothing to do with this. A hopefully helpful observation: When I first load the large image in firefox, zooming in and out several times works fine, without any corruption and Xorg uses 87 MB of RSS memory. It is after changing desktop, scrolling in okular etc that it becomes corrupted. When it becomes corrupted, Xorg use drops to 54 MB of RSS memory. Doesn't this lead to the conclusion that there is some error during memory management? If this were a hardware error, wouldn't Xorg memory use remain constant?
This hasn't occurred since I upgraded to openSUSE 12.2.
This hasn't occurred for quite a while. I assume it's fixed in the current version of the driver stack. Closing.
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.