Red Hat Bugzilla – Bug 55831
XFree86 4.1.0 crashes on startx on Toshiba 660CDT laptop
Last modified: 2007-04-18 12:38:05 EDT
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):
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.
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.
Created attachment 36762 [details]
X config file from clean install of Redhat 7.1
Created attachment 36763 [details]
X config file from Redhat 7.2 upgrade of 7.1
Created attachment 36764 [details]
XFree log file from successful start of X
Created attachment 36765 [details]
XFree log file from unsuccessful start of X after upgrading from 7.1 to 7.2
I have this problem also, on a Toshiba 220CDS (CHIPS driver). I can work around
by enabling the VESA framebuffer and using fbdev.
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.
Created attachment 37242 [details]
tar-gz of logs and stack traceback from XF86 crash
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
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?
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.
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.
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.
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 ...
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: firstname.lastname@example.org
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.
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.
Redhat 7.3 fixed this problem for me.
Ok, thanks. Closing bug as fixed in 7.3 and CURRENTRELEASE (8.0).