On one of my boxes the second head is a 3DFx Voodoo card. The BIOS has an
unusual mapping strategy for PCI space which results in the 3DFx Expansion ROM
being mapped at 0xFFFF0000 for 64K. This fits but XFree86 complains about it and
refuses to initialize the BIOS mappings.
(EE) TDFX(0): Cannot read V_BIOS
It also moans about I/O port mapping errors reporting
(WW) ***INVALID IO ALLOCATION*** b: 0xffffff00 e: 0xffffffff correcting
I've no idea where the I/O allocation error is coming from. I'd be interested to
know if the V_BIOS one looks like XFree86 does something daft or if I should go
looking to see if that is a kernel bug
3Dfx cards can only be used as primary heads currently. Some limitation
in the driver which nobody bothered to implement properly. I recall
David Dawes commenting about it before.
If you change the BIOS to use the other card as secondary, it should work
ok though. Unless of course both are 3Dfx cards. ;o)
I hit send too soon... duh
I'm going to ask upstream for information as to why nobody ever changed this,
and try to find out what the problem is.
It worked for me in 4.1 but not 4.0 on a different set up - Trident Cyberblade
secondary, 3Dfx Voodoo 4500 primary. Of course that may have been luck.
I'll build a test suite for the mmap cases and see if its the kernel anyway
With the 3Dfx primary there, it should work. I haven't heard of reports of
dualhead with 3Dfx as primary failing, except if both heads are 3Dfx, in
which case it might cause problems like reported in some of the emails
I forwarded to you earlier.
Created attachment 58684 [details]
XFree86 log spew
Actually, can you attach the full XFree86.0.log file from startup through
to the end. The info I wanted to look over is cut off.
Defering bug for poking at later on.
Going to assume this one is no longer a problem in FC3/FC4 and close
CURRENTRELEASE, however if it still is a problem, someone should file
a bug report in X.Org bugzilla, so it's tracked in the community
Setting status to "CURRENTRELEASE"