Summary: | Sporadic corruption of hardware cursor. | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Chris Rankin <rankincj> | ||||
Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||
Status: | RESOLVED DUPLICATE | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | medium | ||||||
Version: | unspecified | ||||||
Hardware: | x86 (IA32) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Chris Rankin
2011-05-02 06:31:53 UTC
This might be a duplicate of bug #28426, but with a completely different use-case. 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 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.
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. 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. Possibly a duplicate of bug 46796. Can you try the patch there or a 3.4 kernel snapshot? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c4353016dac10133fa5d8535af83f0c4845a2915 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0349af70da5e590793986a0e03dbf2a435f75103 (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... 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. (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. *** 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.