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 tracker... Setting status to "CURRENTRELEASE"