Bug 65867

Created attachment 59349 [details]
Working config file (with line commented)

Created attachment 59350 [details]
/proc/pci contents

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
remember.

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 ***