Bug 74841 - C&T 69000 hard lockup XFree86
Summary: C&T 69000 hard lockup XFree86
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-02 03:25 UTC by Warren Togami
Modified: 2007-04-18 16:46 UTC (History)
4 users (show)

Fixed In Version: FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-12-01 21:43:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
List of XF86Config options (682 bytes, text/plain)
2002-12-14 08:44 UTC, Warren Togami
no flags Details

Description Warren Togami 2002-10-02 03:25:41 UTC
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

How reproducible:

Steps to Reproduce:
1. Install RH 8.0 in graphical mode on a VA Linux 1000 server (with C&T 69000 video)

Actual Results:  
Hard freezes entire machine eventually.  Scrolling any scroll bar seems to
trigger it easily.

Expected Results:  
Shouldn't freeze up.

Comment 1 Warren Togami 2002-10-02 03:28:40 UTC
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.

Comment 2 Warren Togami 2002-10-02 07:29:51 UTC
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.

Comment 3 Alexander Larsson 2002-10-07 09:17:36 UTC
This looks like an anaconda issue rather than redhat-config-xfree86.
Although the real fix might be in hwdata.

Comment 4 Alexander Larsson 2002-10-07 09:23:27 UTC
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
above options)?

Comment 5 Warren Togami 2002-10-07 17:50:15 UTC
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...

Comment 6 Alexander Larsson 2002-10-08 14:12:48 UTC
sounds like an anaconda issue.

Comment 7 Mike A. Harris 2002-10-09 07:22:53 UTC
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
the future.


Comment 8 Warren Togami 2002-10-27 21:38:49 UTC
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...

Comment 9 Michael Fulbright 2002-11-05 20:37:06 UTC
Any status?

Comment 10 Warren Togami 2002-11-05 22:15:42 UTC
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

Comment 11 Warren Togami 2002-12-14 08:44:51 UTC
Created attachment 88720 [details]
List of XF86Config options

Comment 12 Warren Togami 2002-12-14 08:56:10 UTC
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- next.

Comment 13 Warren Togami 2002-12-15 03:24:12 UTC
Test Results with XFree86-
Full acceleration works great.  Experienced lockups in any cases.

Comment 14 Warren Togami 2002-12-15 03:24:55 UTC
Oops, that should read "Did not experience any lockups."

Comment 15 Warren Togami 2002-12-28 11:04:56 UTC
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.

Comment 16 Jeremy Katz 2003-01-10 07:09:49 UTC
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.

Comment 17 Mike A. Harris 2003-01-10 07:43:14 UTC

Comment 18 Mike A. Harris 2003-01-10 07:52:07 UTC
>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.

Comment 19 Alan Cox 2003-01-10 10:15:18 UTC
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.

Comment 20 Alan Cox 2003-01-10 10:16:14 UTC
PS: Driver has option "noaccel", why not paste in Option "accel" when you are
disabling the accel by default ?

Comment 21 Mike A. Harris 2003-01-11 01:51:37 UTC
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:

Option "swcursor"

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.

Comment 22 Mike A. Harris 2003-01-15 09:45:52 UTC
XFree86- contains a patch to disable acceleration on
C&T 69000.

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.


Comment 23 Warren Togami 2003-01-15 11:15:27 UTC
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.

Comment 24 Mike A. Harris 2003-01-15 13:58:51 UTC
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.

Comment 25 Warren Togami 2003-01-15 18:58:29 UTC
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?

Comment 26 Mike A. Harris 2003-01-15 19:18:51 UTC
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.

Comment 27 Warren Togami 2003-10-23 21:00:28 UTC
Mike, specifically which patch disables accel on this chip?  I have both
motherboards out of production now so I can test it again.

Comment 28 Graham Knap 2004-03-25 19:34:18 UTC
I've got a machine with a C&T 69000. It is a Teknor VIPer 830
single-board computer.

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?

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