Bug 55831 - XFree86 4.1.0 crashes on startx on Toshiba 660CDT laptop
Summary: XFree86 4.1.0 crashes on startx on Toshiba 660CDT laptop
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-07 13:47 UTC by gwasson
Modified: 2007-04-18 16:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-11-11 12:38:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
X config file from clean install of Redhat 7.1 (3.69 KB, text/plain)
2001-11-07 13:48 UTC, gwasson
no flags Details
X config file from Redhat 7.2 upgrade of 7.1 (3.69 KB, text/plain)
2001-11-07 13:49 UTC, gwasson
no flags Details
XFree log file from successful start of X (18.48 KB, text/plain)
2001-11-07 13:50 UTC, gwasson
no flags Details
XFree log file from unsuccessful start of X after upgrading from 7.1 to 7.2 (17.78 KB, text/plain)
2001-11-07 13:51 UTC, gwasson
no flags Details
tar-gz of logs and stack traceback from XF86 crash (4.67 KB, application/octet-stream)
2001-11-11 22:32 UTC, sdh4
no flags Details

Description gwasson 2001-11-07 13:47:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014

Description of problem:
X crashes on startup on Toshiba 660CDT laptop (uses a C&T65554 chipset). X
worked fine on RH71 (XFreee 4.0.3), but doing either a clean install of
7.2, or an upgrade from 7.1 to 7.2, causes X (4.1.0) to no longer work.

I am attaching my XF86config from the 7.1 and 7.2 installations, along with
the XFree86.log file from each installation.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install Redhat 7.2

Actual Results:  get a fatal server error: Caught signal 11. Server aborting.

Expected Results:  X should have started normally.

Additional info:

I am resubmitting this bug since it was closed due to the log file I
attached earlier was from an attempt to troubleshoot the problem by
recompiling XFree from RH's source RPM. I am now submitting the correct log
files from the redhat 7.1 and 7.2 distributions.

Comment 1 gwasson 2001-11-07 13:48:20 UTC
Created attachment 36762 [details]
X config file from clean install of Redhat 7.1

Comment 2 gwasson 2001-11-07 13:49:59 UTC
Created attachment 36763 [details]
X config file from Redhat 7.2 upgrade of 7.1

Comment 3 gwasson 2001-11-07 13:50:48 UTC
Created attachment 36764 [details]
XFree log file from successful start of X

Comment 4 gwasson 2001-11-07 13:51:27 UTC
Created attachment 36765 [details]
XFree log file from unsuccessful start of X after upgrading from 7.1 to 7.2

Comment 5 sdh4 2001-11-11 22:24:26 UTC
I have this problem also, on a Toshiba 220CDS (CHIPS driver). I can work around
by enabling the VESA framebuffer and using fbdev.

Comment 6 sdh4 2001-11-11 22:30:39 UTC
In my case, everything worked on this laptop with R.H. 7.1, using XF3.3.x.
I also used XF4.0.3 under 7.1 via RPM's pulled from RawHide. Now, with 7.2,
XFree86 dumps core on startup. I will attach the relevant logs. 

Comment 7 sdh4 2001-11-11 22:32:40 UTC
Created attachment 37242 [details]
tar-gz of logs and stack traceback from XF86 crash

Comment 8 Mike A. Harris 2001-11-12 08:32:28 UTC
There have been some bug fixes in the XFree86 CVS head IIRC.  It
is possible this may be fixed when 4.2.0 is released in the end
of November.

Comment 9 Andrew Huntwork 2002-02-13 18:15:33 UTC
I also have this problem on my compaq armada 3500 laptop.  Does XF 4.2 fix this?
 Does redhat plan to release XF 4.2 for RH 7.2 anytime soon, or is rawhide the
way to go?

Comment 10 Mike A. Harris 2002-02-13 20:06:38 UTC
I don't know if 4.2.0 fixes this or not as I do not have any trident
hardware, however, many Trident fixes are present in 4.2.0, so it
is highly likely it may work.

There are no plans of making XFree86 4.2.0 available as an official
update for RHL 7.x at this time, however that doesn't preclude it from
becoming an update at some point in time.

Rawhide developmental packages are all there are at this point.  We
need people to test them, so if there are bugs in them they stand a
chance at getting fixed in time for our next official release.

Comment 11 Andrew Huntwork 2002-03-06 19:42:26 UTC
rawhide XFree86 4.2.0 rpms fix this problem, kinda.  The default options for the
chips driver cause my laptop to lockup to the extent that the power switch
doesn't even work, but if I add Option "XaaNoScreenToScreenCopy", then
everything works fine.  Maybe that's cause I haven't actually hit anything that
uses other accelerations yet, but so far, I'm happy.

Comment 12 Andrew Huntwork 2002-03-07 02:35:17 UTC
So this isn't as good as it looked, but I have another workaround.  I guess I
should note that I'm using a 69000.

Two things that reproducably caused machine lockups:

loading cnn.com with galeon
continously scrolling text in an Eterm

I thinking there was some interaction with moving the mouse cursor while these
things were happening, because the workaround is:

Option "hw_cursor" "off"

With this option set, I could safely remove the workaround described previously.

Hopefully I really am set this time.

Comment 13 Alexei Podtelezhnikov 2002-03-07 20:25:31 UTC
From your log file I noticed that you are using 4.1.0-3 from the original RH7.2.
What about 4.1.0-15 errata release? ftp://updates.redhat.com/7.2/en/os/i386 ...

Comment 14 Mike A. Harris 2002-07-26 07:37:59 UTC
The CT69000 reports above are considered a separate bug, and are
reported in another bug report.  Please look at bug #63284, and add any
comments, etc. to that bug report if you like.

To the original bug reporter: gwasson@bellatlantic.net

Can you reproduce this problem still on Red Hat Linux 7.3?  If so,
please try using Option "noaccel" in your config file to see if that
makes any difference.  If it does, we can then try to troubleshoot
and narrow down where the problem resides.

Also, the current rawhide XFree86 contains an updated chips driver
which you may want to try.

Comment 15 Mike A. Harris 2002-09-05 19:48:31 UTC
Is this problem fixed for you in Red Hat Linux 7.3, or in rawhide or one
of our betas?  If so please let me know so I can close the bug as "RAWHIDE".
Otherwise please update the report with current status so something can
be done to fix or workaround the problem.


Comment 16 Mike A. Harris 2002-11-11 04:41:13 UTC

Comment 17 gwasson 2002-11-11 12:38:28 UTC
Redhat 7.3 fixed this problem for me.

Comment 18 Mike A. Harris 2002-11-11 15:50:35 UTC
Ok, thanks.  Closing bug as fixed in 7.3 and CURRENTRELEASE (8.0).

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