Red Hat Bugzilla – Bug 74841
C&T 69000 hard lockup XFree86
Last modified: 2007-04-18 12:46:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Description of problem:
Red Hat 8.0 hard lockups during the installer randomly on the VA Linux 1000
server with the C&T 69000 video chipset. I highly suspect this is the same
lockup as Bug 63284 where the C&T 69000 video controller locks up when using
certain acceleration features. These were worked around by adding
XaaNoPixmapCache and XaaNoCPUToScreenColorExpandFill to the default
configuration of XFree86 after the installer completes.
I suspect that Anaconda isn't using these workarounds during install time with
the native X drivers, so this problem is again causing lockups.
Version-Release number of selected component (if applicable):
Red Hat 8.0
Steps to Reproduce:
1. Install RH 8.0 in graphical mode on a VA Linux 1000 server (with C&T 69000 video)
Hard freezes entire machine eventually. Scrolling any scroll bar seems to
trigger it easily.
Shouldn't freeze up.
Oops, correction to the above. XaaNoPixmapCache seems stable, the two options
that have prevented crashes in the past have been XaaNoScreenToScreenCopy and
I will retest after my text install completes.
Correction again, upon booting into the operating system, I have found that the
two workarounds inserted before Red Hat 7.3 are gone from the XF86Config file.
Bug 63284 has returned.
This looks like an anaconda issue rather than redhat-config-xfree86.
Although the real fix might be in hwdata.
Hmmm. The cards database seems to add "XaaNoPixmapCache",
"XaaNoScreenToScreenCopy" and "XaaNoCPUToScreenColorExpandFill".
What generated the XF86Config file you are using (the one that doesn't have the
The XF86Config generated immediately after a text install didn't have those
three options. I manually added the two (except XaaNoPixmapCache), but this
seems to crash now while it didn't in Red Hat 7.3. NoAccel seems to keep it stable.
Further testing needed...
sounds like an anaconda issue.
Can you please disable noaccel, and experiment with the XaaNoXXX
options, and try to narrow it down? If we can find options that work
reliably, I can modify the driver at least to be stable, and narrow down
the code paths.
So this problem seems a dual problem. Buggy X driver, and also bad
default configuration options from anaconda. If we can get those XaaNo
options that do work though, we can make things stable by default in
Tested a bit more. "XaaNoPixmapCache",
"XaaNoScreenToScreenCopy" and "XaaNoCPUToScreenColorExpandFill" also crashes
now. I don't have time to narrow it down at the moment but NoAccel does prevent
the complete system lockup.
Will test more soon...
I spent another hour last night attempting to find a combination of XaaNo
options that will prevent this lockup, but ran out of time. This takes a very
long time to test all combinations because booting this system after a hard
lockup takes 2-4 minutes.
For now I highly suggest making NoAccel the default. It will not be until late
December when I will have time to test all combations of XaaNo to isolate the
Created attachment 88720 [details]
List of XF86Config options
Test Results with XFree86-4.2.0-72
XaaNoScreenToScreenCopy seems to prevent hard lockups that occurr almost
immediately when you move the mouse in XFree86. When this one option is used
things appear to be very stable with one exception. Macromedia Flash 6 plugin
while visiting http://www.macromedia.com causes the entire system to lockup hard.
When using all options listed in the attachment above, the the Flash animation
still triggers the lockup. When using Option "NoAccel" the system works fine.
What is the difference between NoAccel and all of the XaaNo options?
Testing with Rawhide XFree86-184.108.40.206-0.20021210.0 next.
Test Results with XFree86-220.127.116.11-0.20021210.0
Full acceleration works great. Experienced lockups in any cases.
Oops, that should read "Did not experience any lockups."
Experiencing very rare lockup in Phoebe. Seems to occur during extended use of
the X after 20-30 minutes. I will do more testing to attempt to isolate this crash.
Either hwdata needs to be updated to contain the proper options or X needs to
use the proper options by default, but anaconda's just going to follow those two.
>What is the difference between NoAccel and all of the XaaNo options?
NoAccel completely disables 2D acceleration, leaving everything done in
software. XaaNo options disable individual pieces of 2D acceleration
one at a time.
>Experiencing very rare lockup in Phoebe. Seems to occur during extended
>use of the X after 20-30 minutes. I will do more testing to attempt to
>isolate this crash.
Since you indicated things work much better than before a few comments ago,
and later report that you are still having a problem, I don't want to
disable the options that were disabled before, as the situation seems
to have changed now. The problem with me forcefully disabling accel in
the driver, is that you can't manually re-enable it in order to pinpoint
what the problem is later. The result is that people will just use the
working but unaccelerated driver, and there is less likelyhood that
anyone will ever actually fix whatever the bug is.
However, this bug has trickled on for quite some time, and in an effort to
make the driver stable as possible, with speed purely a secondary issue,
I'm going to disable acceleration for this chip in the driver completely.
If you want to pinpoint the specific options that give you a stable working
driver, please do so with the driver you've got now (make a backup copy
of the chips driver before upgrading to newer releases), and then submit
the results of testing when you've narrowed things down. For now I'm
removing acceleration, but I'll re-enable it in the future if you can
narrow things down.
Mike - I see you cc'd me but the 69000 is very different to the 65534/65550
stuff that I have - its the next generation ("Wingine" I believe). My first
guess would be turning on software cursor and seeing if the lockup is like the
others where the driver used the same RAM for command queue and mouse pointer.
In 8.0 I see loss of commands under high load with the 65550 which isn't common
enough to be annoying but does suggest a bug of this nature or somewhere else in
the queue handling for the old C&T stuff.
PS: Driver has option "noaccel", why not paste in Option "accel" when you are
disabling the accel by default ?
Alan: Yeah, I CC'd you as you're the only other person I could think
of who has obscure hardware like C&T. ;o)
You do bring up a good idea though. Warren, keep all acceleration enabled,
and instead disable the hardware mouse cursor with:
See if the problems go away. If so, we can disable the hwcursor by default
instead of disabling acceleration. That would be a better solution IMHO.
Thanks Alan for the idea.
XFree86-18.104.22.168-20021230.6 contains a patch to disable acceleration on
Setting to MODIFIED. Please test and close as RAWHIDE if it works, or
set to ASSIGNED if it doesn't work, or if you perform the XaaNo testing
and narrow it down to a smaller subset of accel to disable and would like
to have that implemented instead.
Sorry about my slow action on this testing. One of my two motherboards with
this chipset broke, and the other is in production at the local high school.
Reproducing the crash takes about 30-60 minutes of continous desktop use which
is excruciating to do.
The XaaNo testing is optional. The new driver disables acceleration, so
as long as that works properly once tested, the issue is resolved. However,
if the XaaNo testing is performed, and results in a set of options that
also resolve the issue, I can disable just the faulty parts instead of all
Note that XaaNo testing must be tested on the XFree86 you've got already.
If you upgrade to my new version, XaaNo will not do anything as accel
is completely disabled.
It will probably be a while before I can test again since my remaining
motherboard is in production use. When that time comes, is there a simple
change I can make to the XFree86 source to re-enable accel?
No, not in the latest builds. I need something I can ship that is known
to work around the problem. I assume my latest patch works around this.
This presents 2 possibilities now:
1) The current build works, and is slow
2) The current build is broken and unless someone tests it and reports back
in time, our OS will ship with non-functional C&T 69000 support
3) Someone tests a build from December until they nail down the specific
XaaNo options that are needed instead of noaccel, and lets me know,
then tests a build with those options set instead.
Mike, specifically which patch disables accel on this chip? I have both
motherboards out of production now so I can test it again.
I've got a machine with a C&T 69000. It is a Teknor VIPer 830
I'm actually running Debian "sid" (unstable), X packages version
4.3.0-7; but a message in /var/log/XFree86.0.log brought me here:
(WW) CHIPS(0): Acceleration is disabled by default on C&T 69000 as it
has been reported to be broken:
I'm posting here to ask whether there's some way I can help to get
this problem resolved -- since I have the hardware, and maybe some
spare time :-)
BTW, I tried putting Option "accel" in my XF86Config-4 but this seemed
to have no effect. Maybe that's not actually a valid option?