Bug 55831
| Summary: | XFree86 4.1.0 crashes on startx on Toshiba 660CDT laptop | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | gwasson |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.2 | CC: | ash, sh1 |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-11-11 12:38:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
gwasson
2001-11-07 13:47:28 UTC
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 of November. 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: gwasson 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. Thanks. Hello? Redhat 7.3 fixed this problem for me. Ok, thanks. Closing bug as fixed in 7.3 and CURRENTRELEASE (8.0). |