Red Hat Bugzilla – Full Text Bug Listing
|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>|
|Version:||7.2||CC:||ash, geobo, hihihi, vflorins|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-07-17 05:42:11 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description brandon 2001-12-24 13:04:27 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: Apps such as Chromium (evidence in URL provided) and Tuxracer produce garbled output. glgears (xscreensaver) runs fine. Using all stock (X, XF86config-4, dri/glx modules, etc.) I have changed the AGP setting (from 1x to 4x) in config and I also tried the .o modules (mga, etc.) from www.matrox.com to no avail. No noticeable errors that I can see, simply garbled output. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Run Chromium, Tuxracer or (I assume) any other GL app in X. Actual Results: Garbled output. Expected Results: Nice 3d gaming pleasure :) Additional info:
Comment 5 Vladimir Florinski 2001-12-24 23:57:42 EST
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.
Comment 6 Mike A. Harris 2002-01-24 19:12:19 EST
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.
Comment 7 Vladimir Florinski 2002-01-26 03:41:13 EST
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.
Comment 8 Mike A. Harris 2002-02-09 14:34:47 EST
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
Comment 9 Andrew Huntwork 2002-03-06 01:29:22 EST
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
Comment 10 Mike A. Harris 2002-12-19 04:28:05 EST
Does this still occur in RHL 7.3 and/or RHL 8.0? What about rawhide (if anyone has tried rawhide XFree86)? TIA
Comment 11 Vladimir Florinski 2003-01-04 18:28:15 EST
The bug is still present in RH 7.3. I don't have 8.0, so cannot comment on that.
Comment 12 Mike A. Harris 2003-04-15 04:34:15 EDT
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
Comment 13 Mike A. Harris 2003-07-17 05:41:45 EDT
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.