Red Hat Bugzilla – Bug 63284
C&T 69000 Acceleration locks up in XFree86 4.2.0
Last modified: 2007-04-18 12:41:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020405
Description of problem:
I upgraded my VA Linux 1000 server with Chips & Technologies 69000 graphics chip
(2MB SGRAM) from Red Hat 7.2 to Skipjack beta 2.
XFree86 4.2.0 freezes the entire console after some mouse movement.
CTRL-ALT-Backspace or CTRL-ALT-FX keys do nothing. I am able to SSH or serial
into the machine, but kill -9 does not kill X. If I attempt to poweroff or
change the runlevel, the entire machine hard locks.
This troubleshooting page suggests Option "noaccel" on the 690xx chips if this
sort of problem occurs. This stops the X freezing.
My other identical server still running Red Hat 7.2 with XFree 4.1.0 is working
fine with acceleration enabled. It seems that 4.2.0 broke acceleration on this
Version-Release number of selected component (if applicable):
XFree86-4.2.0-6.52 (Skipjack beta 2)
Steps to Reproduce:
1. Setup Skipjack with 1024x768x16 resolution on VA Linux 1000 server.
2. Run X, move mouse around.
X freezes, local console completely locked up. Cannot kill X process. Shutdown
causes complete hard lock up.
Please attach X server log and config file.
Created attachment 53727 [details]
I will post the XFree log when I have physical access to the machine on
Ok. I'm setting "noaccel" as the default for this card for now.
Has this been reported upstream so it can be fixed for the next XFree release?
I will get that XFree log later today.
Created attachment 54004 [details]
XFree86 log retrieved via SSH after X froze
I have seen the same symptoms with 7.3 on a Toshiba Tecra 510CDT. This has
the C&T 65550 graphics controller. I am sometimes able to run for a few
minutes before the machine locks up. I have not tried to remote log into the
machine, but from the machine itself there is no response and it must be power
cycled. I have seen this with KDE and GNOME.
Since noaccel seems to fix this, could one of you whom can reproduce this
problem, please try the following and report back, as it will result in
significant speed improvement over noaccel:
Read the XF86Config man page, and you will find near the middle to bottom
of the manual options XaaNoxxxxxxxx listed. Remove Option Noaccel from
your config file, and replace it with one of the XaaNoxxxx options instead.
Start up X and see if it works. If not, quit X, and remove that option,
and try the next one in line.
This will do two things:
1) You will eventually locate the offending acceleration problem, and be
able to disable just that one part of acceleration, while retaining
accel for everything else. This is a better interim workaround until
a proper solution can be found.
2) Provide me with the XaaNo option that solves this, and I can set it
to default to that, and report it upstream so the driver maintainer knows
what portion of the code is buggy.
This will result in a much sooner real fix, and decent performance in
the mean time.
6 hours and 15 server crashes later, I think I've finally isolated the problem
here. Testing this was especially difficult because it was not a single
problem, but a combination of several problems. These boxes take 2-3 minutes to
get through the BIOS screen and begin booting. =(
These two options prevent crashes that occur very quickly. It appears that
these crashes are independent of each other.
The the lack of this option causes a crash, but only VERY rarely. I can
reproduce this crash 100% by logging into KDE, running kmatrix.kss then
attempting to log out. Sometimes if it doesn't crash here I must click Cancel
and try again. Has something to do with the entire screen filling with a darker
color while the animated kmatrix.kss is running.
Do you need any more information? This server must go back into production soon.
I've updated the chips driver in rawhide to the latest version from
XFree86 CVS. Please try it and provide feedback.
If it doesn't work, I will use the above settings for defaults in the
I did more testing in XFree86 of both Red Hat 7.3 XFree86-4.2.0-8 and Rawhide
XFree86-4.2.0-51.22 rebuilt with rpm --rebuild. I may have been wrong about the
lack of XaaNoPixmapCache causing crashes, though it is difficult for me to be
sure. What can I do in X in order to test the stability of this acceleration
I ran through all the tests again with both XFree86-4.2.0-8 and
XFree86-4.2.0-51.22 and I could find no differences. Within both, the lack of
XaaNoScreenToScreenCopy causes hard locks very quickly at both 800x600x16 and
1024x768x16. The lack of XaaNoCPUToScreenColorExpandFill causes hard locks in
1024x768x16 but not 800x600x16 when running in kmatrix.kss running manually, and
attempting to log out (with the entire KDE screen covered with the faded color.)
Do you advise anything else to test? How can I test XaaNoPixmapCache?
I've changed the Cards database to disable the broken 2D acceleration
primitives by default for the CT69000. This is in rawhide currently.
If you become aware that this gets fixed upstream in the future, and
are able to test it out, please reopen this bug report and we can
remove the workaround in a future RHL release.
Fedora Core 3 developmental hwdata package has been updated to remove
the XaaNo options after Warren confirmed via IRC that the options do
not seem to be needed in X.Org X11 6.7.0 anymore. If these problems
recur for any C&T 69000 users in future Red Hat X.Org packages, please
reopen new bug reports, linking back to this one if need be.
Should a regression occur in the driver in the future, we'll need
to know which XaaNo options are required to work around the issue,
so the driver can hopefully get fixed upstream by Egbert or someone
familiar with the hardware, or alternatively have the primitives