Created attachment 37871 [details] corrupted pixmaps hardware : 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 9100 IGP (prog-if 00 [VGA controller]) Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device f362 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 Memory at e8000000 (32-bit, prefetchable) [size=64M] I/O ports at c000 [size=256] Memory at ec020000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at ec000000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon kernel : 2.6.34-12-desktop (openSUSE 11.3), using KMS radeon driver xorg driver : 6.13.1 Mesa 7.8.2 (openSUSE 11.3 package) when starting GNOME-Shell (2.29.1) with clutter 1.2.8 (or gnome-shell git, compiled against clutter 1.3 branch), if I open gnome-shell application menu, all pixmaps displayed in gnome-shell become corrupted, as well as application window shadows. Kernel sometimes states : radeon 0000:01:05.0: e3e1b280 reserve failed for wait
Does mesa from git work any better?
I've done more tests (with gnome-shell 2.29.1 + clutter 1.2.8): -with Mesa 7.8.2 and KMS disabled, I don't see any pixmap corruption (but gnome-shell become very slow) -with Mesa git and KMS disabled, windows are not visible at all (only the shadow is visible) and gnome-shell is also very slow. I'll do more tests tomorrow, when gnome-shell git is buildable again, since I think the slowness was fixed in git.
Ideally you'd use mesa git and kms as that enables additional hw-accelerated GL functionality (readpixels, etc.) that should improve gnome-shell performance.
hmm, trying mesa git with kms is even worse ATM : gnome-shell (2.29.1) doesn't respond to anything and does refresh correctly ; kernel states : drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream. See dmesg for more info.
Can you attach your dmesg when that happens?
Created attachment 37925 [details] kernel message log
new test with Mesa 7.8.2, KMS enabled, gnome-shell git / clutter 1.3 branch git and kernel 2.6.35.1 I still have pixmap corruptions but kernel is more informative : [ 107.999140] [TTM] Failed to find memory space for buffer 0xc4667c2c eviction. [ 107.999151] [TTM] No space for c4667c2c (5462 pages, 21848K, 21M) [ 107.999157] [TTM] placement[0]=0x00070002 (1) [ 107.999161] [TTM] has_type: 1 [ 107.999164] [TTM] use_type: 1 [ 107.999167] [TTM] flags: 0x00000002 [ 107.999170] [TTM] gpu_offset: 0xE4000000 [ 107.999174] [TTM] size: 16384 [ 107.999177] [TTM] available_caching: 0x00060000 [ 107.999181] [TTM] default_caching: 0x00040000 [ 107.999189] [TTM] 0x00000000-0x00000100: 256: used [ 107.999194] [TTM] 0x00000100-0x00000101: 1: used [ 107.999199] [TTM] 0x00000101-0x00000201: 256: used [ 107.999204] [TTM] 0x00000201-0x0000021d: 28: free [ 107.999208] [TTM] 0x0000021d-0x00000373: 342: used [ 107.999213] [TTM] 0x00000373-0x0000039b: 40: free [ 107.999218] [TTM] 0x0000039b-0x000003ab: 16: used [ 107.999223] [TTM] 0x000003ab-0x00000dd9: 2606: free [ 107.999228] [TTM] 0x00000dd9-0x00001084: 683: used [ 107.999232] [TTM] 0x00001084-0x00002332: 4782: free [ 107.999237] [TTM] 0x00002332-0x00002832: 1280: used [ 107.999242] [TTM] 0x00002832-0x00002d32: 1280: used [ 107.999247] [TTM] 0x00002d32-0x00004000: 4814: free [ 107.999252] [TTM] total: 16384, used 4114 free 12270 I'll try to increase AGP apertuse in BIOS (currently, 64MB)
I've bumped AGP aperture to 256MB, it fixes some corruptions but not all of them and mutter sometimes crashes and I get when it crashes : *********************************WARN_ONCE********************************* File r200_swtcl.c function r200_swtcl_flush line 309 Rendering was 7 commands larger than predicted size. We might overflow command buffer. ***************************************************************************
Bumping VRAM to 64MB fixed r200_swtcl.c warnings. I've upgraded Mesa to 7.9RC2 and this corruption is fixed (there is other issues but there is a also a lot of Cogl errors, so it might be Clutter master bugs). 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.