Bug 36769 - Sporadic corruption of hardware cursor.
Summary: Sporadic corruption of hardware cursor.
Status: RESOLVED DUPLICATE of bug 46796
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2011-05-02 06:31 UTC by Chris Rankin
Modified: 2012-04-06 06:14 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Screenshot that fails to capture the problem, but shows something else instead. (169.48 KB, image/jpeg)
2011-06-19 06:28 UTC, Chris Rankin
no flags Details

Description Chris Rankin 2011-05-02 06:31:53 UTC
This problem has been happening on and off for a long time. Basically, the hardware cursor graphic sometimes disappears and is replaced by a large square of seemingly random garbage instead. (Although the garbage isn't entirely random, because its colours tend to reflect the contents of the screen, and I have occasionally recognised part of an icon inside which happened to exist within my gnome panel at the time.)

The circumstances when this corruption happens are always the same: while playing World of Warcraft, I have been pressing the buttons which make the character "run" - and WoW always hides the cursor while these buttons are pressed. When I stop running, the cursor *sometimes* reappears corrupted. (I don't have any reliable way of triggering the bug.)

This only happens with my RV350 desktop, and never with my NVIDIA laptop. (Same versions of WoW and Wine, etc.) The corruption also continues when I exit WoW, and the only way I have found to restore the cursor is to restart X. For these reasons, I have decided that the best place to raise this bug is against the Radeon Xorg driver.
Comment 1 Chris Rankin 2011-05-03 16:34:39 UTC
This might be a duplicate of bug #28426, but with a completely different use-case.
Comment 2 Chris Rankin 2011-05-08 06:58:28 UTC
For the first time *ever* today, this corruption has magically "fixed" itself about 30 minutes after it started happening. Is this the most unlikely memory corruption event in human history, or a clue as to what the actual underlying problem with the hardware cursor really is?

The xorg driver is from git, with the latest commit being:

commit 90abffbd30f44b9cf76a6e28103ddcb5419b4522
Author: Ilija Hadzic <ihadzic@research.bell-labs.com>
Date:   Fri May 6 09:45:23 2011 -0400

    DRI2: fix high-crtc/vblank oversight/bug
Comment 3 Chris Rankin 2011-06-19 06:28:51 UTC
Created attachment 48160 [details]
Screenshot that fails to capture the problem, but shows something else instead.

This bug hit me again this afternoon, and so I tried to capture a screenshot. What I was seeing on the screen was a large randomly-coloured square where my hardware cursor should be, but I have discovered this screenshot shows something else instead:

This image *should* contain WoW's cursor graphic, which is a grey gauntlet with a finger pointing to the "hotspot. What it shows instead is Fedora 15's cursor graphic, which is a small black arrow.

For the record, when this bug happens, I don't even get Fedora 15's arrow cursor back even when I quit WoW. I am therefore *amazed* to see it sitting happily in the middle of my screenshot.
Comment 4 Chris Rankin 2011-06-19 09:25:36 UTC
I have since tried taking a WoW screenshot on a machine running the NVIDIA binary blob, and this also shows the Fedora arrow cursor instead of the WoW cursor. So the only thing I can say for sure is that I cannot capture an image of the icon corruption.
Comment 5 Chris Rankin 2012-01-02 15:52:51 UTC
This bug is still happening with Fedora 16's Xorg and the xf86 radeon_drv.so from git. I believe I've also seen this problem happen (once) while logging out of GNOME3 shell too, so don't think that WoW can be blamed.
Comment 7 Chris Rankin 2012-04-06 03:55:36 UTC
(In reply to comment #6)
> Possibly a duplicate of bug 46796.
Or vice versa?

> Can you try the patch there or a 3.4 kernel snapshot?
I believe that this patch has now been added to both 3.2 and 3.3 stable trees too. And no, the problem hasn't reoccurred yet - but it's still early days. I never had a reliable method of triggering it in the first place, so I can only *really* be sure if it *isn't* fixed...
Comment 8 Michel Dänzer 2012-04-06 04:06:42 UTC
If your card has more than 128M of VRAM (that's just one reason why Xorg.0.log and dmesg should be attached to every bug report...), let's mark this as a duplicate of bug 46796, which has more information about the likely cause and its fix. If you ever hit it again, we can go from there.
Comment 9 Chris Rankin 2012-04-06 05:10:05 UTC
(In reply to comment #8)
> If your card has more than 128M of VRAM...

256 MB, to be exact:

radeon 0000:01:00.0: putting AGP V3 device into 8x mode
radeon 0000:01:00.0: GTT: 256M 0xC0000000 - 0xCFFFFFFF
[drm] Generation 2 PCI interface, using max accessible memory
radeon 0000:01:00.0: VRAM: 256M 0x00000000E0000000 - 0x00000000EFFFFFFF (256M used)
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 444042 kiB.
[TTM] Zone highmem: Available graphics memory: 1037688 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 256M of GTT memory ready.
Comment 10 Alex Deucher 2012-04-06 06:14:08 UTC

*** This bug has been marked as a duplicate of bug 46796 ***

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.