Red Hat Bugzilla – Bug 65867
Xconfigurator generates config that locks up system with ATI|Radeon QD (DRI)
Last modified: 2007-04-18 12:42:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
Xconfigurator correctly detects my video card as an ATI|Radeon QD (I don't think
that's what the box said, but it's probably the real name), but when DRI is
enabled in the XFree86-4 configuration and I am using >8bpp, the machine locks
whenever going into X. (Complete lock, no ctrl-alt-backspace, no switching
terminals, etc.) I can successfully use Xconfigurator if I skip the tests and go
to edit the config file by hand, commenting out the DRI module.
This might be better filed as a generic XFree86 v4.2 problem, but since
Xconfigurator should work anyway, I thought I would file it here. Please feel
free to reassign.
Version-Release number of selected component (if applicable): 4.10.7-1
Steps to Reproduce:
2.Verify that monitor and card detected correcly, select any amount of RAM up to
32. (What I have on the card.)
3.Select any >8bpp mode
4. Don't skip the test.
Actual Results: Machine locks hard. No escape without reset button.
Expected Results: Text successful, I can see the test screen at 16bpp. (or above)
Created attachment 59349 [details]
Working config file (with line commented)
Created attachment 59350 [details]
I've reassigned to XFree86, as it is a Radeon driver bug, not Xconfigurator.
Radeon QD is the ASCII representation of the Radeon chip PCI device ID. (0x5144)
ATI chips are generally refered to by their ASCII ID, as it's easier to
This problem is known, and we're looking into the problem. It occurs on
most Radeon hardware in 4.2.0, and is a problem that was unfortunately
introduced with 4.2.0.
The current workaround is to either disable DRI, or just not switch VT's
until the issue can be fixed.
I disagree somewhat with this response. I agree that it is a Xfree 4.2 problem
and a known issue, but I disagree that Xconfigurator shouldn't be fixed to
workaround the bug until the XFree drivers can be repaired. The smart option to
me seems to either be to have Xconfigurator take your suggestion and disable
DRI (the easy route) or call XFree 4.x unfit for Radeons and have them default
back to XFree 3.x for the time being.
This is really unfair on the non-adept who can't figure out how to configure
their video by hand. Since even the RedHat installer is broken, it's somewhat
of a sad situation. Immediately after install, I had to boot with
init=/bin/bash, change the inittab default runlevel to 3, and reboot before I
could even get on the system to start tweaking the X configs. That's a sad road
for a newbie.
Also, not switching VTs isn't the answer because it seems to happen the first
time X is entered on boot. I don't know of a way to get into X without hitting
text mode first. :)
Xconfigurator isn't broken and needs no changing. You're suggesting
changing the default configuration, and that is not done by modifying
Xconfigurator, but by modifying the Cards database, which is part of
the hwdata package. Disabling stuff randomly on one of the most popular
line of video cards which people expect to work, and which DOES work for
many people without fully understanding the problem is not at all a smart
thing to do. We simply did not, and still do not have enough information
about the problem at this stage.
We have no idea of the scope or statistics of how many people the problem
occurs for, and how many it does not occur for. Once that data is acquired,
it is entirely possible that it works fine for 95% of the users out there,
and doesn't work for 5%. Having the configuration default to disabling
features that work for 95% of people is not a good idea IMHO. And at any
rate that decision would have had to been made PRIOR to 7.3 being released,
at which time even less information was known. Changing it now and
releasing an erratum of the Cards file is not going to solve the problem.
My Radeon QD's all work fine on 2 machines for what it is worth. I only
see a problem on Radeon 7500 and some other Radeon hardware.
It is also possible that the problem I am talking about, and the problem
you are reporting are two separate issues.
Disabling DRI by default, and then receiving 50 times the incoming bug reports
claiming that DRI should be enabled by default but it is disabled, and
that once it was enabled, it worked fine is not something that I would
consider a better workaround for the problem.
The real problem will be resolved only once enough data is gathered,
and someone is able to debug it and find a solution. On the Radeon 7500
for example, someone has now been able to give the following data:
Disabling DRI makes the problem go away, with DRI enabled, every VT switch
causes a hang. With DRI enabled, and the Vidmode extension disabled, every
second VTswitch causes a hang. This is new data received within the last
12 hours of which I've not had a chance to investigate.
Unless there is a severe influx of all Radeon users or a large majority of
them reporting this problem, it is insane to change the default to disable
DRI. You're of course completely free to disagree and I wont hold it
against you. ;o)
I'm more interested in solving the real problem though. Let me know
if DRI with Vidmode disabled gives you the same results.
*** This bug has been marked as a duplicate of 62171 ***