Bug 154502

I have exactly the same problem wuth my laptop toshiba - sattelite, what i tried
to resolve the problem is to build the x11-xorg srpm again with and without some
of the fedora patches, I had no success in some of the builds, but even if could
manage to build the rpms the problem was not solved. I think it's something with
feedora gcc4.0/xorg patches/mess, because I'm happily using xorg 6.8.2 on the
same laptop with another distro to which I'm stuck at the moment.

Thanks for the bug report.  We have reviewed the information you
have provided above, and there is some additional information we
require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X
server log file (/var/log/Xorg.*.log) to the bug report as individual
uncompressed file attachments using the bugzilla file attachment link
below.

We will review this issue again once you've had a chance to attach
this information.

Thanks in advance.

Created attachment 113230 [details]
/etc/X11/xorg.conf for trident cyberblade

This is my /etc/X11/xorg.conf

Created attachment 113231 [details]
/var/log/Xorg.0.log

From runlevel 3, I execute as root
[root@foobox ~]# X
I confirmed white sceen and then type Ctrl+Alt+Backscreen.

Sorry, not a Ctrl+Alt+Backscreen, but Ctrl+Alt+Backspace.

I have the same problem too. FC3 is OK, FC4T2 freezes on a blank white screen.

I also have the same problem.
It does not freeze, but you must go through the install blindly :-(
Is there any boot parameter, which can force X to use vesa driver?

>I think this has been happen sinse GCC4 rebuilding.

Random guesses as to what is causing the problem don't really help
find the actual problem.

>manage to build the rpms the problem was not solved. I think it's something with
>feedora gcc4.0/xorg patches/mess, because I'm happily using xorg 6.8.2 on the

Again, while it is unfortunate that you are experiencing this problem,
and it is likely very frustrating, making random guesses as to what
has caused the problem does not make the problem go away, nor help
us to try to find a solution.

The patches applied to our X.org rpm packages are a collection of bug
fixes which are either already checked into the upstream stable 6.8.x
branch or are in upstream bugzilla nominated for inclusion in 6.8.3
because they fix bugs.  Some of the other patches we include are
bug fixes which are not yet nominated for 6.8.3 but will be.

Wether the patches are included directly in X.Org sources yet or not,
or applied on top of them, doesn't really justify calling it a "mess".

Would people prefer us to ship the stock sources, and not fix any bugs?
I think not.  It's not possible to fix bugs without applying patches
however.  So that "mess" is what makes people's computers work when
the stock upstream source code does not.

Something to keep in mind.

We unfortunately don't have any Trident video hardware, so it is
recommended to file a bug report in X.Org bugzilla at
http://bugs.freedesktop.org in the "xorg" component, so that the
Trident video driver maintainer will be aware of the problem people
are experiencing with this video chipset, and he might have some
suggestions to try, or even perhaps have a new experimental driver
for testing purposes.

Once you've filed your report in X.Org bugzilla, please paste the URL
here, and we will track the issue in X.Org bugzilla and review any
fixes that become available for consideration to add to our patch
"mess" for future updates, so that Trident users can hopefully have
a solution to this problem without having to wait for the next major
release of Xorg 5 months from now.  ;o)

Attach to the X.Org bug report, your X server log and config file
as individual uncompressed file attachments, as this will be useful
information for developers troubleshooting the issue.

It is also a good idea if you can extract the trident_drv driver out
of the FC3 rpm package as you've mentioned the problem did not exist
in FC3.  Then rename the FC4 trident driver to .bak or something, and
put the FC3 driver in place.  Indicate if the problem goes away or not.

If the issue does go away, it is possible that the trident driver
has regressed in some manner, and this will provide Xorg developers
with very useful information in diagnosing the issue and finding a
solution.

è¶æå«:

>I also have the same problem.
>It does not freeze, but you must go through the install blindly :-(
>Is there any boot parameter, which can force X to use vesa driver?

You can do a text mode install, and then configure X afterward manually
by doing "system-config-display --reconfig".  You can manually edit
the config file and switch to vesa as a temporary workaround if that
happens to work.

Hope this helps.

Setting status to "NEEDINFO", awaiting upstream bug report URL.

I already did it.
I replaced /usr/X11R6/lib/modules/drivers/trident_drv.o with FC3's one,
and got same problem.
I found a bug #2976 in Xorg bugzilla. I will send infos.

Tracking http://freedesktop.org/bugzilla/show_bug.cgi?id=2976

*** This bug has been marked as a duplicate of 151688 ***

Update:  We believe this issue might be related to bug #161242.  Please
review that bug, test the workaround indicated in it, and provide feedback.
If it turns out to be the same issue, it'll be fixed when we resolve
bug #161242.

Thanks again.

I replaced FC4's /usr/X11R6/lib/modules/libvgahw.a with FC3's one,
and confirmed that this workaround works for trident CyberBlade.

Thanks for testing the workaround, and for the prompt update.  We'll track
the issue in the master bug now.

*** This bug has been marked as a duplicate of 161242 ***