Bug 98524 - BusID disregarded in xorg.conf in dual graphics card and single monitor setup
Summary: BusID disregarded in xorg.conf in dual graphics card and single monitor setup
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.7 (2012.06)
Hardware: PowerPC Linux (All)
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
: 98534 (view as bug list)
Depends on:
Reported: 2016-11-01 04:16 UTC by Mingcong Bai
Modified: 2018-12-17 17:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Full Xorg.0.log (17.11 KB, text/plain)
2016-11-01 04:16 UTC, Mingcong Bai
no flags Details

Description Mingcong Bai 2016-11-01 04:16:57 UTC
Created attachment 127656 [details]
Full Xorg.0.log

I was playing with a graphics card upgrade on my PowerMac G5 Quad... The reason why I did a dual card setup is that I wanted to keep the old card with Apple BIOS so my system could actually boot, and a newer Radeon HD6570 for the Linux desktop (without Apple BIOS, which makes it impossible to use the card alone).

More information could be found with Luigi's post on graphics card upgrades with Ubuntu:


In the section about video setup, he pointed out specifically about the fact that we would need to install the newer card on the G5's PCIe x8 slots instead of the x16 one. Which I found to be true when I ran into the issue described here (while X could be initialized, the GPU acceleration was disabled):


"Full dmesg attached. I have a Power Mac G5 (late 2005, PCIe) with a Radeon HD 6450 (CAICOS, x86 BIOS) installed on the PCIe x16 slot, and I get this error (*) on boot. I also have a GeForce 6600 (Open Firmware) on a PCIe x8 slot, which works fine, minus the usual nouveau caveats. I have no idea if this is related at all, but the x16 slot is directly connected to the U4 northbridge, and is capable of bypassing the DART IOMMU for 64-bit DMA capable devices (like the Radeon). The other slots are connected to a PCIe bridge on the HyperTransport bus, and DMA always goes through the DART. If needed, I can provide ssh access to the machine."

Note: [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) 

But after I swapped the Radeon card into the x8 slot, and the NVIDIA GeForce 6600 (with Apple BIOS) back into x16 - X will not start, possibly due to a card mismatch...


So, let's get to the details: I have the following xorg.conf in /etc/X11 (which I am not sure if it's correct, there might be stupid mistakes in it).


Section "Device"
  Identifier "Device0"
  Driver "radeon"
  BusID "PCI:6:0:0"
  Option "Monitor-VGA-1" "VGA screen"

#Section "Device"
#  Identifier "NV"
#  Driver "nouveau"
#  BusID "PCI:6:0:0"
#  Option "Ignore" "true"
#  Option "Disabled" "true"
#  Option "Monitor-DVI-0" "DVI screen"

Section "Screen"
  Identifier "Default"
  Device "Device0"
  Monitor "VGA screen"
  DefaultDepth 24
  SubSection "Display"
    Depth 24

Section "Monitor"
  Identifier "VGA screen"

And to match the information, here's the `lspci` output (discarded all non-VGA output):

0000:0a:00.0 VGA compatible controller: NVIDIA Corporation NV43 [GeForce 6600 ...
0001:06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Turks PRO [Radeon HD 6570/7570/8550]
0001:06:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Turks HDMI 
Audio [Radeon HD 6500/6600 / 6700M Series]

I think it is quite clear that the output above shows that the two cards I have on the system are of different PCI domains (according to the PCI ID format). Whenever I try to start LightDM, however, the PCI probing seems always favor the NVIDIA card from the 0000 domain, despite I specified the AMD card with a PCI ID at 6:0:0, although in the 0001 domain:

(Is there a way to specify domain in the BusID setting?)

Here below is a sample of the Xorg.0.log (full version attached below):

[   882.106] (II) xfree86: Adding drm device (/dev/dri/card0)
[   882.110] (--) PCI:*(0:10:0:0) 10de:0142:10de:0010 rev 162, Mem @ 0xa2000000/16777216, 0xa8000000/134217728, 0xa1000000/16777216, BIOS @ 0x????????/131072
[   882.110] (--) PCI: (1:6:0:0) 1002:6759:1682:3198 rev 0, Mem @ 0x90000000/268435456, 0x80140000/131072, BIOS @ 0x????????/131072

As you can see, it has chosen the NVIDIA card (according to the `lspci` output once again). When I swapped the AMD card to the x16 slot (effectively putting it in the 0000 domain, and the NVIDIA in the 0001 domain), which X did not seem to ever select the NVIDIA card in the x8/x4 slots.

Here's a speculation, is it true that xorg.conf have no support for PCI domain specification (which did not seem to be true, as I have tried "PCI:1:6:0:0" before, which led to the same result)? Or is it the matter that X simply selects cards from the order of PCI domains - if so, is there a way to "reverse" it?
Comment 1 Michel Dänzer 2016-11-02 01:28:23 UTC
*** Bug 98534 has been marked as a duplicate of this bug. ***
Comment 2 Merlijn Boris Wolf Wajer 2017-01-26 21:32:13 UTC
I have tried this today. And I run into the same problem. I dug in the xorg-server code and found the right way to pass the domain for BusID.

File: ./hw/xfree86/common/xf86pciBus.c
Function: xf86ParsePciBusString

Contains this comment:

The format is assumed to be "bus[@domain]:device[:func]", where domain bus, device and func are decimal integers.  domain and func may be omitted and assumed to be zero, although doing this isn't encouraged.

This works:

# cat /etc/X11/xorg.conf.d/force-card.conf 
Section "Device"
	Identifier  "Card0"
	Driver      "radeon"
	BusID       "PCI:6@1:0:0"

Hope this helps.

FWIW, I think this is two separate bugs:

1) xorg.conf is underdocumented when it comes to the PCI domains in BusID
2) xorg autodetect doesn't seem to deal with PCI domains
Comment 3 Merlijn Boris Wolf Wajer 2017-01-29 14:52:33 UTC
If my previous comment wasn't clear - I think this "bug" is easily fixed by simply documenting the BusID option for xorg.conf a bit nicer. It doesn't seem to be a radeon bug.

Perhaps the original reporter can say whether my 'fix' works for him/her?
Comment 4 GitLab Migration User 2018-12-17 17:34:26 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/614.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.