Bug 77473 – Xorg not scanning past PCI bus 0

• Status: RESOLVED UPSTREAM
• Product: Gentoo Linux

[Description richard chan 2005-01-10 23:29:17 UTC]

Radeon card (Sun XVR-100) in a SunFire V210z is not found by xorg-x11-6.8.0-r3
PCI bus scan as the scan stops at bus 0.

Here's the PCI scan
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 108e,a801 card 0000,0000 rev 00 class 06,00,00 hdr 00
(II) PCI: 00:06:0: chip 10b9,7101 card 0000,0000 rev 00 class 00,00,00 hdr 00
(II) PCI: 00:07:0: chip 10b9,1533 card 0000,0000 rev 00 class 06,01,00 hdr 00
(II) PCI: 00:0a:0: chip 10b9,5237 card 0000,0000 rev 03 class 0c,03,10 hdr 00
(II) PCI: 00:0d:0: chip 10b9,5229 card 0000,0000 rev c4 class 01,01,ff hdr 00
(II) PCI: End of PCI scan

Here's the device list - the graphics card is on Bus 3:
0000:00:00.0 Class 0600: 108e:a801
0000:00:06.0 Class 0000: 10b9:7101
0000:00:07.0 Class 0601: 10b9:1533
0000:00:0a.0 Class 0c03: 10b9:5237 (rev 03)
0000:00:0d.0 Class 0101: 10b9:5229 (rev c4)
0001:00:00.0 Class 0600: 108e:a801
0001:00:02.0 Class 0200: 14e4:1648
0001:00:02.1 Class 0200: 14e4:1648
0002:00:00.0 Class 0600: 108e:a801
0002:00:02.0 Class 0100: 1000:0021 (rev 01)
0002:00:02.1 Class 0100: 1000:0021 (rev 01)
0003:00:00.0 Class 0600: 108e:a801
0003:00:01.0 Class 0300: 1002:5159             //ATI Radeon Card
0003:00:02.0 Class 0200: 14e4:1648
0003:00:02.1 Class 0200: 14e4:1648

Reproducible: Always
Steps to Reproduce:
1. Start Xorg

Actual Results:  
No graphics card found

Expected Results:  
Expected X to launch on console

Notice that it doesn't scan past bus 0.

[Comment 1 Ciaran McCreesh 2005-01-10 23:33:12 UTC]

What kernel are you running?

[Comment 2 richard chan 2005-01-11 03:02:51 UTC]

Observed since varions gentoo-dev-sources-2.6.9-rX. Currently, 
running gentoo-dev-sources-2.6.10-r1.

I'm running with a radeon framebuffer console (RADEON_OLD); this works
so at least the fb code is scanning other host bridges. This machine
reports 4 PCI host bridges - so it seems to have four PCI trees.
radeon dri module also detects and loads successfully.

[Comment 3 richard chan 2005-01-11 06:17:18 UTC]

Googling - this seems to be a known problem that PCI domains (<---didn't
know host bridges were called that) are not probed properly. Need to
investigate further. Anyway 
xc/programs/Xserver/hw/xfree86/os-support/linuxPci.h
seems to have the domain 0000: hard-coded?

[Comment 4 richard chan 2005-01-11 13:36:39 UTC]

The XFree86 code base has also changed linuxPci.c to try
to "walk" the PCI domains properly - i.e., it now
enumerates domain/bus/dev/id
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c?rev=1.12&content-type=text/vnd.viewcvs-markup

I'll report this upstream to Xorg to incorporate this
kind of change.

[Comment 5 Jason Wever (RETIRED) 2005-03-12 07:53:41 UTC]

If you've opened an upstream bug, can you post it here so we can track it?  Thanks.

[Comment 6 Donnie Berkholz (RETIRED) 2005-05-24 01:18:49 UTC]

Please post any upstream bug here.

[Comment 7 richard chan 2005-05-24 01:34:54 UTC]

Known problem in Xorg (upstream).

https://bugs.freedesktop.org/show_bug.cgi?id=827

Fixed by maintainer in 

https://bugs.freedesktop.org/show_bug.cgi?id=2368

[Comment 8 richard chan 2005-05-24 01:42:43 UTC]

Another user encountered this upstream bug on a totally different card/arch - in
his case Matrox/POWER where the card lands up in a non-zero PCI domain - it is
not Sparc64 specific.

See 

https://bugs.freedesktop.org/show_bug.cgi?id=433

[Comment 9 Donnie Berkholz (RETIRED) 2005-05-24 10:10:50 UTC]

Thanks!