Having thought about this overnight I think that the problem must be connected
to the fact that there is an on-board graphics card as well as the PCI radeon card.

During the install the anaconda system probes for the graphics and monitor - and
I noted that the graphics is always detected as the Trident on-board card even
though the monitor (which IS correctly probed) is plugged in to the PCI radeon card.

It seems that it is pointing to the system incorrectly assigning the wrong
graphics card into which the monitor is plugged that may be the root cause of
this bug.

If I plug the monitor into the onboard graphics card then nothing appears on the
screen at all during boot.

Therefore I am wondering if there is a kernel parameter that I could use to make
the installer use the correct graphics card if I were to re-install to get a
graphical rather than a text install ?

Equally is there a kernel parameter that I might add to the kernel line in grub
to make the system see the correct card with the existing installed system?

There are a number of very similar postings on various list sites which have
indicated an analogous problem when there are two graphics cards in the system
and this may also point to a wider issue with dual head systems, particularly if
one (or both) are radeon cards.  I am not convinced this is a radeon driver
issue since I have two other machines with radeon cards which installed fc5
without a problem though these are both machines with only a single graphics card.

Mike

I have had have a few extra thoughts - maybe there is a kernel parameter
that can be passed to the kernel at boot to select the correct card - I
think the crux of the issue is that the system detects the Trident but then
correctly finds the monitor and it is on a different card ! So there is a
conflict.  Perhaps adding pci=reverse to the boot paramters ??

Certainly during the install the probe detected the onboard Trident graphics,
but the output was to the monitor connected to the Radeon PCI card.

I wondered if adding the "BusID parameter to the xorg.conf in the graphics
device definition might get it to boot (which I will try when I can get back to
the machine) - I guess the BusID is listed on lspci ? It has been hard to find
documents on this - if there are useful links to accessible information on this
 then it would be valuable to publicise them ?

After much googling I found some secrets well buried. I found out that
if you run lspci and get the BusID from the first line of the graphics
card entry, say 0:0d.0, then you can specify this in the xorg.conf
file for example:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        VendorName  "Videocard vendor"
        BoardName   "nVidia Corporation NV34M [GeForce FX Go5200]"
        Screen  0
        BusID   "PCI:0:13:0"
EndSection

It seems that the trick is to convert the hex value from the lspci
output into a triplet of colon separated decimal values - hence the 13 above in
the PCI:0:13:0.

This possibly points to issues related to dual head operation - and I did note
there is a Redhat Magazine article on this issue at:
http://www.redhat.com/magazine/014dec05/features/multihead/

I am also now wondering if this is a bug related to the kernel as it looks to me
like there is conflicting information being used such as the graphics card
detected in two places but the system not recognising that the monitor is
connected to the card it is plugged into ?  

Although the xorg mods I have as a possible solution may lead me to a
workaround, perhaps there is a kernel bug that needs to be investigated ?

I know that there are postings from users of dual head systems that have had
almost the same problem as I have found in my system. For example:
http://forums.fedoraforum.org/forum/showthread.php?t=103112&highlight=anaconda+graphics+card

Any help would be very much appreciated.

Mike

I am now wondering if this was triggered by a kudzu problem initially - since it
is possible that the correct card was not assigned as primary on the install.

After all it knows which the monitor is connected to so it should associate the
graphics card it is connected to with the associated driver and bus ?

Mike

(In reply to comment #1)
> Having thought about this overnight I think that the problem must be connected
> to the fact that there is an on-board graphics card as well as the PCI radeon
card.
> 
> During the install the anaconda system probes for the graphics and monitor - and
> I noted that the graphics is always detected as the Trident on-board card even
> though the monitor (which IS correctly probed) is plugged in to the PCI radeon
card.
> 
> It seems that it is pointing to the system incorrectly assigning the wrong
> graphics card into which the monitor is plugged that may be the root cause of
> this bug.
> 
> If I plug the monitor into the onboard graphics card then nothing appears on the
> screen at all during boot.
> 
> Therefore I am wondering if there is a kernel parameter that I could use to make
> the installer use the correct graphics card if I were to re-install to get a
> graphical rather than a text install ?

The kernel is not involved in video card or monitor autodetection like
that.  It is kudzu which performs video hardware autodetection.

 
> Equally is there a kernel parameter that I might add to the kernel line in grub
> to make the system see the correct card with the existing installed system?

Try removing the video card, and installing using only the onboard video.
Does the installation proceed correctly?

After installation, plug the other card in.  Make sure that you go into your
BIOS's CMOS settings and configure it to make the correct video device the
primary video device.  Note that some systems do not provide this option,
which makes setups like this a bit more difficult per se.

 
> There are a number of very similar postings on various list sites which have
> indicated an analogous problem when there are two graphics cards in the system
> and this may also point to a wider issue with dual head systems, particularly if
> one (or both) are radeon cards.  I am not convinced this is a radeon driver
> issue since I have two other machines with radeon cards which installed fc5
> without a problem though these are both machines with only a single graphics card.

If you can't install using the above advice, do a text mode install instead.

Once you have the OS installed correctly, run the following command from
the commandline:

system-config-display --reconfig

This will force the userland tools to redetect the video card(s), and the
attached display(s).

Does X start properly on the correct display(s) now?

If not, please attach the X server log file from this session, as well as
the xorg.conf generated by the above system-config-display invocation.

Thanks in advance.

Thank you for the reply Mike.  I will reply today even though I am temporarily
at home recovering from a broken leg ! So it might be a day or two before I can
test the system again and report back.

Concerning your last comment - I presume that you implied that the install
graphical or text should be done with the onboard video card only, and then one
done to add in the PCI radeon card - and only then try to boot into a text
console and run system-config-display.  I believe that is the process that I did
when FC4 came out last year which you helped resolve at the time
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169637)

I will look again at the BIOS settings but I could not find the appropriate
setting when I last looked at the system last week.

I will report back in a few days when I have managed to get into work for a day.

In the meantime thank you for helping me out.

I removed the radeon card and ran the install from scratch again. The graphical
install went without a hitch, and the post install, and firstboot were fine.

At this point, once the system was running I configured everything, and set a
yum -y update going - and now have no time to continue testing. So it is running
with the onboard video only, and no PCI graphics card.

It may be some time before I can continue testing the system.

However this surely points to a problem with the kudzu detection of the original
two graphics cards - or the way in which the system handles and assigns the
cards once detection is complete. It is certainly not logical for the system to
be able to detect two cards and then assign the graphics card which has no
monitor attached to it!!

I have seen so many postings about serious problems with systems containing two
graphics cards that this seems an area that needs looking into for FC6 maybe ?

I do not have the knowledge to determine if it is a kudzu problem or an X
problem but there is certainly a bug here somewhere.

At a later stage when I do get time to investigate further I will post here.

The X server can only start based on how it was configured, so this seems
to either be a bug in kudzu, or s-c-d.  Picking kudzu for now and
reassigning.

Going back to the initial issue... there is no reason why it should *hang* on
startup. X (for rhgb) should merely fail to start. Something else is causing the
hang.

Hardware no longer available in original form and now running F7. Therefore I am
closing this bug as insufficient data.