Red Hat Bugzilla – Bug 468943
radeonhd-20081014git finds wrong BIOS for secondary card
Last modified: 2009-09-06 12:36:20 EDT
Created attachment 321736 [details]
Xorg.log file for radeonhd BIOS misdetection
I have an x86_64 system with two Radeon GPUs, an HD 3200 (RS780) on the motherboard plus a PCIe HD 2600XT (RV630), and I would like to run multicard multiseat. In the motherboard BIOS I have "SurroundView" enabled, which makes the PCIe card primary but still allocates UMA for the motherboard GPU. X runs fine on the primary card. When I try to run X on the secondary GPU with IsolateDevice, it incorrectly uses the BIOS information of the primary card:
(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(II) RADEONHD(0): ATOM BIOS Rom:
SubsystemVendorID: 0x1462 SubsystemID: 0x0990
BIOS Bootup Message:
113-MSITV099MS.211 RV630XT HYNIX 32MX16 256MB DUAL DVII+TVO
This is the information from the primary card, the RV630. As a result it soon fails with "Failed to detect a connected monitor". This occurs with the latest rawhide RPM, xorg-x11-drv-radeonhd-1.2.3-1.2.20081014git.fc10.x86_64. I've attached the full Xorg.log file.
As a side note, if I disable SurroundView on the motherboard and make the onboard GPU primary, then when I try to run X on the secondary card, it fails to find the secondary BIOS at all:
(II) RADEONHD(0): Getting BIOS copy from PCI ROM
(EE) RADEONHD(0): rhdAtomGetTables: No AtomBios signature found
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
Reporter, is this still an issue? Does it work with xorg-x11-drv-ati?
Subsequent investigation led me to the conclusion that the problem is in xorg-x11-server and the way it handles primary card detection when IsolateDevice is in use. I have filed a separate bug on that in June, Bug 505679, although it is still status NEW and hasn't been assigned.
So I am closing this bug and marking it as a duplicate of Bug 505679. I hope that is the correct administrative dispensation for this bug.
*** This bug has been marked as a duplicate of bug 505679 ***