I have an IBM p614 (POWER4, PCI) with a PCI G450. This card is for POWER. I'm *not* trying to use an x86 card in a POWER box. :) The system installed with pretty vanilla SLES-9 and X.org 6.7.0 (from CVS). I can see the Matrox card with lspci. It is shown at "0001:62:00.0". I have tried several variations of calling out the BusID (both "PCI:1:62:0" and "PCI:1:98:0" thinking lspci gives hex and X.org wants decimal) and ChipID (the device is 0x0525, just like every other G400 / G450 in the world) in the Device section of my config file. Right after the driver loads and logs a message saying which chips it supports, I get: (EE) No devices detected. I'm fresh out of ideas. I know the device is there because I can get X using the fbdev driver.
It appears that the problem is that the card ends up in PCI domain 1, but multiple PCI domains are not supported on POWER Linux. It appears that only SPARC and Alpha have this support.
Known problem in scanning PCI domains; is this problem fixed by https://bugs.freedesktop.org/show_bug.cgi?id=2368 See also https://bugs.freedesktop.org/show_bug.cgi?id=827 (BTW I see exactly the same problem as you: Radeon on Sparc64 system, Matrox on OpenPOWER - both cases graphics card is on some other PCI domain and X -scanpci will not find the card.)
Created attachment 3215 [details] [review] Add support for dashed splines I have just verified that this problem still exists, even when the card is in a domain 0 slot. For whatever reason, the PCI probe process finds the card, but finds it at the *wrong* address. I've attached a patch that disables the use of vgaHW if fbdevHW is used (a similar patch was needed for Radeon and Rage128 on PowerPC). This patch also adds some debug output.
Created attachment 3216 [details] generated postscript xorg.conf file
Created attachment 3217 [details] generated postscript Xorg.0.log file
Created attachment 3218 [details] pdf which causes the problem (example 2) "lspci -vvv" output
I've done a *LOT* more digging into this problem, and I've made some important discoveries. It seems that on pSeries systems, PCI bus addresses and PCI CPU addresses, even for 32-bit processes, are different. Other systems, such as x86-64, 32-bit PowerPC, and other 64-bit PowerPC (e.g., G5 based PowerMacs) map these to the same values. The problem, which only appears on pSeries, is that the routines that map from bus address to CPU address are not properly used in all the places where they should be. The result is that when resource lists are created, the CPU address ranges are used. However, when driver code tries to find the resources for its device, it uses the bus addresses. When these addresses are not the same, the driver can't find the resources for its device. As would be expected, the driver bails. I'm working on a patch (that I should be able to post later today) that fixes at least some of these problems. I'll detail the problems that still exist when the patch is posted.
Any status update on that patch Ian, or is this something that will be resolved with the pci-rework?
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Fixed by PCI-rework.
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.