From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009
Description of problem:
I am assigning this bug to anaconda, although it may be a redhat-config-xfree86
or firstboot bug.
I did an install on a SMP system with a Fire GL 1000 card:
01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)
Subsystem: Diamond Multimedia Systems FIRE GL 1000 PRO
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
Memory at f4300000 (32-bit, non-prefetchable) [size=128K]
Memory at f5000000 (32-bit, non-prefetchable) [size=8M]
Memory at f4800000 (32-bit, non-prefetchable) [size=8M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities:  AGP version 1.0
During other Red Hat installs, this card doesn't return the probe properly, thus
it defaults to 512K RAM. There wasn't anywhere that I could specify the proper
amount of video RAM, so rhgb didn't fit on the screen and I couldn't see the
Forward/Backward buttons during firstboot. When I logged in, I ran
redhat-config-xfree86, but there is no place to put in the amount of video RAM
either, and when I chose 'Custom' video card, it gave a traceback:
Traceback (most recent call last):
File "/usr/share/redhat-config-xfree86/xConfigDialog.py", line 254, in
File "/usr/share/redhat-config-xfree86/videocardDialog.py", line 179, in dehydrate
carddata = self.videocard.cardsDB()[name]
Obviously it is checking the video card database for a card named Custom, and it
I had to manually edit /etc/X11/XF86Config and under the Device Section:
and then I could change the resolution in redhat-config-xfree86.
I think that it would be prudent to allow a 'Configure advanced video options'
like the 'Configure advanced boot loader options', and a warning in
rhgb/firstboot that states that the resolution is 640x480, which means that they
won't be able to see the entire screen. Maybe it would be possible to make it a
virtual 800x600 so that the screen would scroll as the mouse approached the edge.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install on old video hardware that doesn't probe properly
2. Wait for rhgb/firstboot/redhat-config-xfree86
Actual Results: The minimum 640x480 isn't large enough to see the entire
screen, and there is no place to manually set the proper video RAM except
editing /etc/X11/XF86Config manually.
Expected Results: The best situation for me would be to have an option during
install or via redhat-config-xfree86 to specify video RAM. Otherwise, I would
have appreciated a virtual 800x600 so that I wouldn't have to guess which
buttons that I am tabbing to during firstboot.
All modern video hardware has it's video memory amount properly probed by
the XFree86 video driver. There are a very small number of exceptions to this
rule, however the exceptions don't make the rule of course.
The number of video cards out there that specifically require the user to
set the video memory amount in order to work correctly is extremely small.
In the past, our config tools have had a VideoRAM dialog box option, and we
have observed that when users are presented with the VideoRAM option in a
dialog box, a rather large portion of users will set the VideoRAM amount
wether they need to do so or not. What is worse, is that a large nontrivial
number of users will either inadvertently set this number incorrectly, or
they will think their card has more memory than it really does. When users
set the video memory amount too high, the video driver and X server will
crash and/or deadlock the system, as the driver will now ignore the probed
amount and try to use the amount it has been told is there, leading to random
and unpredictable behaviour.
This has become an increasingly more common problem nowadays. Many users think
incorrectly that because they can see the option to set video memory, that they
should set it, or that it is best to do so.
Due to the high volume of users misconfiguring this option because it is made
too visible in a GUI, and those users then reporting bugs about their video
not working, we have wasted a lot of time debugging and troubleshooting video
driver problems which really were nothing more than end user misconfiguration,
or not knowing how much memory their card truely has, we have removed this
option from the config tools intentionally.
The VideoRAM option has been totally disabled in some of our video drivers,
such as the "radeon" driver, and "savage" driver, as those drivers are known
to properly detect video memory on all supported devices, and many cases of
VideoRAM being specified have resulted in a broken setup. We plan to remove
this option from other drivers in the future, and eventually have it only
functional with hardware which the drivers can't autodetect memory amount.
The VideoRAM option will not be returning to our config tools GUI, however
the option is useable by hand editing the config file and adding it there.
This may slightly inconvenience a small number of users out there who require
this option in order to have their hardware work properly, but it is more
beneficial to inconvenience a small number of users, than to inconvenience
a rather large number of users who use the VideoRAM option when they
specifically do _not_ need to use it, and thus end up breaking their system,
and tying up our precious technical and engineering support services trying
to diagnose problems one at a time as they come in.
The driver for your particular card is provided as-is by Red Hat, since it
is part of a default XFree86 build. While we do not officially support this
hardware, we do provide the driver, and hope it works for people, and will
review upstream fixes or user supplied bugfixes to the drivers for potential
inclusion in future releases.
Users who have hardware that does not work unless VideoRAM is specified, should
file a bug report in XFree86 bugzilla at: http://bugs.xfree86.org
In the report, provide a completely detailed explanation of the problem, and
attach config files and log files as appropriate. If the given driver has an
active maintainer, or an XFree86 developer is familiar with the driver, they
may respond, and may be able to fix the memory autodetection perhaps.
In the mean time, the config file can be modified by hand to work around
If you file a bug upstream, if you put the URL to the upstream bug report
here and I will track it and review the fixes for future erratum.