Red Hat Bugzilla – Bug 142685
x11 hang when dri/glx is use on mga G400 card
Last modified: 2015-01-04 17:13:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
Fresh install of RHEL4 Beta 2 + current updates.
X11 hang when using dri (glxgears, some screensavers).
Graphics card : Matrox G400
The same occur with FC3.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Launch glxgears
Actual Results: X11 hang.
Expected Results: X11 should not hang.
board : "VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]"
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA KT266/KY266x/KT333 chipset
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: AGP aperture is 32M @ 0xe0000000
/etc/X11/xorg.conf and /var/log/Xorg.0.log coming.
PS: I don't find the xorg-x11 compoment.
Created attachment 108407 [details]
Created attachment 108408 [details]
> PS: I don't find the xorg-x11 compoment.
Change component to xorg-x11 :-)
I can reproduce on my system (FC-3 plus latest, somewhat hacked, xorg
from fd cvs)
I have a G400 card since a couple of weeks and never got DRI working.
Try with the latest DRI, DRM, and mga drivers from matrox (
Latest testing kernel fix this bug (2.6.9-1.722_FC3) :
Component set to kernel.
bug fixed with FC3 (2.6.9-1.722_FC3). Not tested with RHEL 4.
This is filed against the RHEL4 kernel, assigned to the X devel
team, and closed as fixed in Fedora Core development.
RHEL4 does not gather erratum from Fedora Core development however,
so this issue either was a bug in FC3 which accidentally got misfiled
against RHEL4, but is now fixed in FC3, in which case we can reopen,
reassign to FC3, and close as RAWHIDE...
or, it is a RHEL4 issue that has also been fixed in the latest
RHEL4 kernel, in which case, the bug should be reopened, and put
into MODIFIED state, and the bug ID of this bug added to the
upcoming RHEL4 U1 kernel advisory tonight.
or it is a RHEL4 issue that is still a bug in RHEL4, but which
the FC3 kernel has been tested on RHEL4 and turns out to not have
This is currently marked as a RHEL4_U1 blocker bug, so I am going
to reopen the issue, reassign to the kernel component owner, and
move it to RHEL4_U2 blocker, because it's too late to get addressed
in RHEL4 U1 if it is not fixed already.
Please indicate if the latest RHEL4 test kernels fix this issue
Sorry for any confusion.
Setting status to NEEDINFO, pending clarification about issue
in RHEL4 specifically, while using an official RHEL4 kernel.
Thanks in advance.
> this issue either was a bug in FC3 which accidentally got misfiled
No. It's real bug in RHEL 4 *beta 2*.
> but is now fixed in FC3
> or, it is a RHEL4 issue
I don't know if it's RHEL4 (final) issue. I know it's a RHEL4 *beta 2*
> still a bug in RHEL4, but which the FC3 kernel has been tested on
RHEL4 and turns out to not have the problem.
I don't do such test.
I don't test RHEL4 (final).
> Please indicate if the latest RHEL4 test kernels fix this issue as well.
I can't. Sorry.
> Sorry for any confusion.
Me too :-)
Ok, thanks for the update.
More puzzling is that around the time the 'fix' happened in FC3, there were no
MGA changes in the kernel. The only thing that changed there in the last 6
months is that its now also built for x86-64.
The one *major* change, was that we dropped the 4g4g patch completely in Fedora
for that release. Given we made a number of 4g4g fixes since beta2, (in
particular a nasty agpgart interaction), was this bug ever confirmed to be in
the final GA kernel ?
If its only seen in beta2, we can close this.
Closing based on lack of response from previous comment. Assuming fixed in GA.