Bug 65867 - Xconfigurator generates config that locks up system with ATI|Radeon QD (DRI)
Xconfigurator generates config that locks up system with ATI|Radeon QD (DRI)
Status: CLOSED DUPLICATE of bug 62171
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
7.3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-03 08:02 EDT by jpranevich
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-16 09:10:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Working config file (with line commented) (1.77 KB, text/plain)
2002-06-03 08:04 EDT, jpranevich
no flags Details
/proc/pci contents (1.96 KB, text/plain)
2002-06-03 08:06 EDT, jpranevich
no flags Details

  None (edit)
Description jpranevich 2002-06-03 08:02:59 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:
Comment 1 jpranevich 2002-06-03 08:04:09 EDT
Created attachment 59349 [details]
Working config file (with line commented)
Comment 2 jpranevich 2002-06-03 08:06:28 EDT
Created attachment 59350 [details]
/proc/pci contents
Comment 3 Mike A. Harris 2002-06-03 20:53:50 EDT
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.



Comment 4 jpranevich 2002-06-03 23:34:28 EDT
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. :)
Comment 5 Mike A. Harris 2002-07-16 09:10:15 EDT
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.
Comment 6 Mike A. Harris 2002-07-26 08:18:08 EDT

*** This bug has been marked as a duplicate of 62171 ***

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