This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 57814 - GL(X) apps garbled with Matrox G450 and stock config/drivers
GL(X) apps garbled with Matrox G450 and stock config/drivers
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
http://www.burn.net/~vom/matrox-glx-p...
: MoveUpstream
Depends On:
Blocks: 82777
  Show dependency treegraph
 
Reported: 2001-12-24 13:04 EST by brandon
Modified: 2007-04-18 12:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-07-17 05:42:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
XFree86.0.log (27.45 KB, text/plain)
2001-12-24 13:27 EST, brandon
no flags Details
/var/log/dmesg (6.04 KB, text/plain)
2001-12-24 13:29 EST, brandon
no flags Details
glxinfo output (2.47 KB, text/plain)
2001-12-24 13:31 EST, brandon
no flags Details
xdpyinfo output (5.88 KB, text/plain)
2001-12-24 13:32 EST, brandon
no flags Details

  None (edit)
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 1 brandon 2001-12-24 13:27:54 EST
Created attachment 41310 [details]
XFree86.0.log
Comment 2 brandon 2001-12-24 13:29:34 EST
Created attachment 41311 [details]
/var/log/dmesg
Comment 3 brandon 2001-12-24 13:31:51 EST
Created attachment 41312 [details]
glxinfo output
Comment 4 brandon 2001-12-24 13:32:13 EST
Created attachment 41313 [details]
xdpyinfo output
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.


Note You need to log in before you can comment on or make changes to this bug.