Bugzilla – Bug 433
[Matrox/G450] Can't load driver for PCI G450 on POWER
Last modified: 2008-06-02 07:48:36 UTC
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
(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]
Created attachment 3217 [details]
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
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.