Bug 433 - [Matrox/G450] Can't load driver for PCI G450 on POWER
[Matrox/G450] Can't load driver for PCI G450 on POWER
Product: xorg
Classification: Unclassified
Component: Driver/mga
Other Linux (All)
: high normal
Assigned To: Xorg Project Team
Xorg Project Team
Depends on: 5277
  Show dependency treegraph
Reported: 2004-04-08 16:49 UTC by Ian Romanick
Modified: 2008-06-02 07:48 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Ian Romanick 2004-04-08 16:49:35 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.
Comment 1 Ian Romanick 2004-04-23 09:55:30 UTC
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.
Comment 2 rspchan 2005-05-24 01:39:15 UTC
Known problem in scanning PCI domains; is this problem fixed by


See also

(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.)
Comment 3 Ian Romanick 2005-08-03 07:26:51 UTC
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.
Comment 4 Ian Romanick 2005-08-03 07:27:16 UTC
Created attachment 3216 [details]
generated postscript

xorg.conf file
Comment 5 Ian Romanick 2005-08-03 07:27:34 UTC
Created attachment 3217 [details]
generated postscript

Xorg.0.log file
Comment 6 Ian Romanick 2005-08-03 07:27:54 UTC
Created attachment 3218 [details]
pdf which causes the problem (example 2)

"lspci -vvv" output
Comment 7 Ian Romanick 2005-08-31 09:40:37 UTC
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.
Comment 8 Erik Andren 2006-06-28 12:10:27 UTC
Any status update on that patch Ian, or is this something that will be resolved
with the pci-rework?
Comment 9 Daniel Stone 2007-02-27 01:23:23 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 10 Ian Romanick 2008-06-02 07:48:27 UTC
Fixed by PCI-rework.