More info:
lspci reports that indeed, one of my devices has its access ranges disabled.
00:0b.0 Non-VGA unclassified device: PLX Technology, Inc.: Unknown device
2784 (rev 03) (prog-if 03)
Subsystem: PLX Technology, Inc.: Unknown device 9056
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 32, cache line size 08
Region 0: Memory at db00 (32-bit, non-prefetchable) [disabled]
[size=512]
Region 1: I/O ports at b800 [disabled] [size=256]
Region 2: Memory at da00 (32-bit, non-prefetchable) [disabled]
[size=16M]
Region 3: Memory at d980 (32-bit, non-prefetchable) [disabled]
[size=1M]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] #06 []
Capabilities: [4c] Vital Product Data
00:0c.0 Non-VGA unclassified device: PLX Technology, Inc.: Unknown device
2784 (rev 03) (prog-if 03)
Subsystem: PLX Technology, Inc.: Unknown device 9056
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR-
Latency: 32, cache line size 08
Region 0: Memory at d900 (32-bit, non-prefetchable) [size=512]
Region 1: I/O ports at b400 [size=256]
Region 2: Memory at d400 (32-bit, non-prefetchable) [size=64M]
Region 3: Memory at d380 (32-bit, non-prefetchable) [size=1M]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] #06 []
Capabilities: [4c] Vital Product Data
Can anyone provide me with some hints were to start looking for this
problem? What would cause
my PCI addresses to be disabled? Presumably the RAC is doing this, but why?
Thanks,
Noel
Ok, I have taken this over from Mike, and I have some more information on
this. The problem seems to be in how the devices are mapped into memory.
BTW, the configuration is actually 3 heads. An ATI VGA card, and my two
Image Systems cards, neither of which has any VGA ability.
During ScreenInit we map in the framebuffers for each card. Right before
ScreenInit exits, I added code to draw a test pattern on the screen, and
then pause for a few seconds so I can view it. This works perfectly for
both heads. Once I return from ScreenInit, things go bad. I added similar
code to the start of SaveScreen, and on the first call to SaveScreen
framebuffer accesses to the first device device cease to work entirely.
Framebuffer access to the second device still work, but seem to be slower
than they should be. Changing the order of the screens in my XF86Sonfig
file changes which screen tanks and which works. It is always the first
screen intalized that fails.
If I remove either screen from the XF86config file, the remaining screen
works perfectly (so simply haveing both boards in the system isn't enough
to cause the failure)
My best guess is that something is happening to my PCI mappings, but how?
Driver has no accelerations in it, all drawing is direct frame buffer
access.
Looking at my log file,
(II) XMP: ImageScreenInit drawing test pattern..
(II) XMP: ImageScreenInit exit.
(==) RandR enabled
Screen 1 is using RAC for mem
Screen 1 is using RAC for io
Screen 2 is using RAC for mem
Screen 2 is using RAC for io
(II) Entity 0 shares no resources
(II) Screen 1 shares mem io resources
(II) Screen 2 shares mem io resources
Why is RAC being used for my driver? Why does it say my screens share mem
and io resources? There are no shared resources on the Image Systems
boards. They do hi-res only and do not have a VGA core. I assume Entity 0
is my ATI card.
Where can I find documetation on how Linux/XFree maps and manages PCI
address spaces? Is it XFree that does this, or the Linux kernel?
Failing system notes and observations:
1. The video hardware does not have a BIOS or VGA core of any kind.
2. The video driver functions properly when using a single head
configuration on either head.
3. The video driver and hardware are 8 bit only, one 1200x1600 mode,
with no accelerations.
4. The primary head is lit and will respond to framebuffer writes
after memory mapping in the driver and
the written data remains unmolested through the entire XServer
session.
5. The cursor appears to move into the drawing area of the primary
head, but is not visible there.
6. Running Xinerama has no effect on the failure to draw on the
primary head.
7. Multimon function is correct when configured to run only one
