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 How reproducible: Always Steps to Reproduce: 1.Run Xconfigurator 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) Additional info:
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 ***