Red Hat Bugzilla – Bug 154502
Installer shows white screen with trident CyberBlade
Last modified: 2007-11-30 17:11:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1
Description of problem:
FC4T1 and FC4T2 graphical installation, I got whole white screen.
And I can't proceed installation. Text installation is going fine.
I tried to append "nofb" kernel option, and got same problem.
After installation, graphical boot and GDM login screen are also whole white.
I pressed Alt+Ctrl+F1 to switch to console.
But console fonts are broken and random garbage was displayed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Insert FC4T1 or FC4T2 installation CD-ROM.
3.Choose graphical installation.
Actual Results: Only whole white screen was displayed.
Expected Results: The graphical installer shows up.
This PC has AMD Duron, VIA VT8361 (KLE133) chipset with trident blade 3D integrated video. The trident driver was choosen by installer.
I changes to the vesa driver from trident driver, then it works fine.
This PC has showed X fine with trident driver when FC1/FC2/FC3.
00:00.0 Host bridge: VIA Technologies, Inc. VT8361 [KLE133] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8361 [KLE133] AGP Bridge
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1
I think this has been happen sinse GCC4 rebuilding.
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
We will review this issue again once you've had a chance to attach
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]
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
>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.
*** 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
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 ***