Bug 63284 - C&T 69000 Acceleration locks up in XFree86 4.2.0
C&T 69000 Acceleration locks up in XFree86 4.2.0
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
Blocks: 61901 67218
  Show dependency treegraph
Reported: 2002-04-11 20:34 EDT by Warren Togami
Modified: 2007-04-18 12:41 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-23 02:31:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config-4 (2.16 KB, text/plain)
2002-04-13 04:51 EDT, Warren Togami
no flags Details
XFree86 log retrieved via SSH after X froze (25.83 KB, text/plain)
2002-04-16 06:30 EDT, Warren Togami
no flags Details

  None (edit)
Description Warren Togami 2002-04-11 20:34:27 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)
XFree86-4.2.0-6.60 (Rawhide)

How reproducible:

Steps to Reproduce:
1. Setup Skipjack with 1024x768x16 resolution on VA Linux 1000 server.
2. Run X, move mouse around.
3. Freeze!

Actual Results:  
X freezes, local console completely locked up.  Cannot kill X process.  Shutdown
causes complete hard lock up.

Expected Results:  
Shouldn't freeze.
Comment 1 Mike A. Harris 2002-04-13 04:06:21 EDT
Please attach X server log and config file.
Comment 2 Warren Togami 2002-04-13 04:51:06 EDT
Created attachment 53727 [details]
Comment 3 Warren Togami 2002-04-13 04:52:11 EDT
I will post the XFree log when I have physical access to the machine on 
Comment 4 Mike A. Harris 2002-04-13 07:00:43 EDT
Ok.  I'm setting "noaccel" as the default for this card for now.
Comment 5 Warren Togami 2002-04-15 16:00:06 EDT
Has this been reported upstream so it can be fixed for the next XFree release?

I will get that XFree log later today.
Comment 6 Warren Togami 2002-04-16 06:30:11 EDT
Created attachment 54004 [details]
XFree86 log retrieved via SSH after X froze
Comment 7 Chris Little 2002-05-13 10:01:36 EDT
 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.
Comment 8 Mike A. Harris 2002-05-13 15:24:28 EDT
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.
Comment 9 Warren Togami 2002-06-19 07:23:48 EDT
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.
Comment 10 Mike A. Harris 2002-06-22 03:55:39 EDT
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
Comment 11 Warren Togami 2002-06-23 02:31:03 EDT
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?
Comment 12 Mike A. Harris 2002-07-26 05:35:25 EDT
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.

Comment 13 Mike A. Harris 2004-08-03 04:05:24 EDT
Status update:

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
disabled upstream.

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