Bug 65526 - XFree86 freaks out with a ROM mapped at memory top
Summary: XFree86 freaks out with a ROM mapped at memory top
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-05-27 00:28 UTC by Alan Cox
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-20 12:43:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XFree86 log spew (5.22 KB, text/plain)
2002-05-27 15:53 UTC, Alan Cox
no flags Details

Description Alan Cox 2002-05-27 00:28:00 UTC
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

Comment 1 Mike A. Harris 2002-05-27 14:26:59 UTC
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)

Comment 2 Mike A. Harris 2002-05-27 14:29:24 UTC
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.

Comment 3 Alan Cox 2002-05-27 14:42:24 UTC
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

Comment 4 Mike A. Harris 2002-05-27 15:29:57 UTC
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.

Comment 5 Alan Cox 2002-05-27 15:53:58 UTC
Created attachment 58684 [details]
XFree86 log spew

Comment 6 Mike A. Harris 2002-05-28 06:23:55 UTC
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.

Comment 7 Mike A. Harris 2002-12-15 09:46:45 UTC
Defering bug for poking at later on.

Comment 8 Mike A. Harris 2005-04-20 12:43:18 UTC
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"

Note You need to log in before you can comment on or make changes to this bug.