Bug 57814
| Summary: | GL(X) apps garbled with Matrox G450 and stock config/drivers | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | brandon | ||||||||||
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | David Lawrence <dkl> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 7.2 | CC: | ash, geobo, hihihi, vflorins | ||||||||||
| Target Milestone: | --- | Keywords: | MoveUpstream | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | i686 | ||||||||||||
| OS: | Linux | ||||||||||||
| URL: | http://www.burn.net/~vom/matrox-glx-problem.png | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2003-07-17 09:42:11 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 82777 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
brandon
2001-12-24 18:04:27 UTC
Created attachment 41310 [details]
XFree86.0.log
Created attachment 41311 [details]
/var/log/dmesg
Created attachment 41312 [details]
glxinfo output
Created attachment 41313 [details]
xdpyinfo output
I have exactly the same problem with a Matrox G200. Intel 440BX motherboard (P3-600), stock RedHat 7.2 kernel (2.4.7), XFree86 4.1.0, running AGP 1x, 16bpp, and a rather standard XFree config. The card worked fine in all previous RedHat versions. Looks like a problem with mga drm. Please try the recently released XFree86 4.1.0-15 erratum, and update the bug report with your latest results. You will need to upgrade Mesa and also the kernel to our latest release as well. I have updated the software as told (now have kernel-2.4.9-21, XFree86-4.1.0-15 and Mesa-3.4.2-10), but nothing has changed. I can now provide additional info: it looks like glx programs cannot use textures. Here's sample output (from chromium, but Quake 2 is very similar): Failed to upload texture, sz 2048 Memory heap (nil): heap == 0 End of memory blocks (this repeats on and on thousands of times, each time with a different number after sz). So the only reason gears work is because it doesn't use textures at all. This seems to me to be a Mesa bug of some kind perhaps. I've reported it upstream to mesa developers to see if it is a known bug or has been fixed perhaps. I'll update the report when more info becomes available. TIA I just upgraded to the XFree86-4.2 in rawhide, and I still see the same thing described herein. I'm running the Mesa-demos programs, and below is a complete list of the demos that cause problems: checker fire gloss mipmap ray (really bad) reflect spectex teapot texbind texenv texobj texsub texturesurf tunnel (really bad) wrap Does this still occur in RHL 7.3 and/or RHL 8.0? What about rawhide (if anyone has tried rawhide XFree86)? TIA The bug is still present in RH 7.3. I don't have 8.0, so cannot comment on that. I hate to ditch a long ago reported bug report like this, but I'm doing it for a very good reason, and for that I will explain. In the scheme of bug report prioritization, video game related bugs get very low priority, since we don't really market the distribution as a video game platform. In general, a 3D acceleration related bug, is a bug in XFree86 or Mesa in general, and they're not usually Red Hat Linux specific. It makes the most amount of sense to report these types of bugs directly to the DRI project as they have a great number of developers whom work on DRI, Mesa, and related code every day, compared to Red Hat which currently has 2 X developers, of whom rarely work with 3D related code ever. Leaving this bug open without commenting on it, really just leaves it open to not ever get investigated like it really deserves to be since there are almost always likely to be higher priority bug reports open that keep these type of reports idle and thus remain unfixed. So, I'm going through bugzilla and finding bug reports that I honestly believe are most likely not ever going to get the attention they deserve, and just trying my best to explain it to people and recommend to them how to report their bug in the respective upstream project and thus increase the chances of someone who actively works on DRI or Mesa all day every day investigating the problem and fixing it. To report the problem upstream, file a bug report at http://bugs.xfree86.org and it will likely be reassigned to the DRI project. The success rate of deferring bugs to upstream developers like this has proven to be quite high since bugzilla opened up upstream, so this is most likely the fastest way to see the problem fixed. I can then much more easily investigate the fixes for inclusion in future RHL releases. If you file it upstream, please include a URL here to link to the bug. Hope this helps. Closing as UPSTREAM Nobody's provided a URL for me to track this bug upstream anywhere, so I can't do so. I'm assuming that people who experienced this bug in action, have upgraded to a newer release and are no longer experiencing the problem, or that interest has been lost in the problem. Reopening bug and closing as WONTFIX. If the problem has been reported upstream anywhere and someone would like it tracked, feel free to reopen this bug and provide the upstream bug URL. Thanks. |