| Summary: | Textures(?) in WoW breaking up until X-server is restarted | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Chris Rankin <rankincj> |
| Component: | Drivers/DRI/r200 | Assignee: | Default DRI bug account <dri-devel> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
Shows "TV static" corruption in World of Warcraft
More grpahical corruption with WoW |
||
|
Description
Chris Rankin
2007-10-21 05:53:59 UTC
Created attachment 12138 [details]
Shows "TV static" corruption in World of Warcraft
Created attachment 12139 [details]
More grpahical corruption with WoW
The corruption moves very quickly, so its hard to capture its true extent.
This corruption still happens with git Mesa as of 25-Oct-2007, although I currently need to play WoW in Direct3D mode due to another bug affecting OpenGL mode. If I play with WoW in a 1024x768 window then the corruption stays as pixel-level noise and does not crash the card. (At least, it hasn't yet.) However, playing in a bigger window results in the problem growing until the scenery starts flashing and card finally locks up. (See previous attachments.) I was wondering - could this bug be the result of heap corruption within Mesa that slowly kills the X server? (In reply to comment #4) > I was wondering - could this bug be the result of heap corruption within Mesa > that slowly kills the X server? since dri clients have their own address space there seems to be little potential for memory corruption (which is still present after client restart). Looks really strange, more like a hardware failure (overheating?). Does it also get fixed if you switch to a console and back? If this is a new issue you could try figuring out which commit caused it with git-bisect. It is not a new issue; I first noticed it a while ago, but it has been getting steadily worse recently. And no, switching to a console and back doesn't reset the problem. I actually need to restart X to do that. (In reply to comment #6) > And no, switching to a console and back doesn't reset the problem. I actually > need to restart X to do that. Hmm, to clarify: restarting X doesn't reset the problem completely after all. But it certainly reduces it. Restarting X stopped the subsequent flickering in celestia, for example. (In reply to comment #5) > If this is a new issue you could > try figuring out which commit caused it with git-bisect. I'm not sure that this is Mesa's fault because I've just compiled Mesa 7.0.1 and rebooted, and the same problem has started again! Could there be something in the DRM module causing this? That might at least explain how the problem can affect celestia after Warcraft. I am running Linux 2.6.23.1: [drm] Initialized drm 1.1.0 20060810 [drm] Initialized radeon 1.28.0 20060524 on minor 0 Mass version move, cvs -> git I've just noticed this patch being added to 2.6.32.x: [patch 079/149] drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00405.html Is there *any* possibility that I was hitting the bug that this patch is fixing here? (I no longer play WoW with my rv280, so can't actually test this hypothesis.) |
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.