Bug 227851 - Second graphics card isn't correctly detected (V_BIOS?)
Summary: Second graphics card isn't correctly detected (V_BIOS?)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-02-08 16:07 UTC by Kevin R. Page
Modified: 2018-04-11 12:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-14 16:48:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
PCI Radeon set as the primary card (GeForce fails as secondary) (71.98 KB, text/plain)
2007-02-08 16:07 UTC, Kevin R. Page
no flags Details
PCIe GeForce as the primary card (Radeon fails as secondary) (81.46 KB, text/plain)
2007-02-08 16:10 UTC, Kevin R. Page
no flags Details
xorg.conf used when first two attachments were generated (2.12 KB, text/plain)
2007-02-09 12:18 UTC, Kevin R. Page
no flags Details
Patch for xorg-x11-drv-ati package (1.24 KB, patch)
2007-02-15 17:44 UTC, Kevin R. Page
no flags Details | Diff
Patch for xorg-x11-server package (11.33 KB, patch)
2007-02-15 17:45 UTC, Kevin R. Page
no flags Details | Diff
Second patch to xorg-x11-server package (1.94 KB, patch)
2007-02-15 17:51 UTC, Kevin R. Page
no flags Details | Diff
Working xorg.conf with patched xserver (1.32 KB, text/plain)
2007-02-15 17:53 UTC, Kevin R. Page
no flags Details
Xorg.0.log after fresh boot - heads detected correctly (71.60 KB, text/plain)
2007-02-15 17:54 UTC, Kevin R. Page
no flags Details
Xorg.0.log following subsequent X restart - heads detected incorrectly (86.64 KB, text/plain)
2007-02-15 17:55 UTC, Kevin R. Page
no flags Details
xorg.conf: PCIe GeFore as primary card (Radeon fails as secondary) (660 bytes, text/plain)
2007-07-11 12:02 UTC, Kevin R. Page
no flags Details
Xorg.0.log: PCIe GeFore as primary card (Radeon fails as secondary) (46.89 KB, text/plain)
2007-07-11 12:03 UTC, Kevin R. Page
no flags Details
xorg.conf: PCI radeon set as primary in BIOS (GeForce fails as secondary) (1.17 KB, text/plain)
2007-07-11 12:07 UTC, Kevin R. Page
no flags Details
Xorg.0.log: PCI radeon set as primary in BIOS (GeForce fails as secondary) (70.87 KB, text/plain)
2007-07-11 12:08 UTC, Kevin R. Page
no flags Details


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 2597 0 None None None Never
Novell 171453 0 None None None Never

Description Kevin R. Page 2007-02-08 16:07:52 UTC
Hardware:
Intel D945GTP motherboard (updated to latest BIOS)
PCIe GeForce 7600GS (using nv driver)
PCI Radeon 9200 Pro / rv280 (using radeon driver)

The PCI Radeon has an LCD panel connected to its DVI port, the PCIe GeForce has
an LCD panel connected to its first DVI port.

Description of problem:
Whichever graphics card isn't set as the primary card in the motherboard BIOS
(i.e. the "secondary" card) fails to work - in each case hardware detection
fails, though in different ways. The failing card will work when set as the
primary, and vice versa.

With the PCI Radeon set as the primary card (GeForce fails as secondary):
The PCI Radeon works fine. The GeForce is detected with 0 VideoRam, and as such
no modes are available. The VideoRam setting has no effect. The logfile (see
attachment) includes:
(II) NV(0): Initializing int10
(EE) Cannot find empty range to map base to
(EE) NV(0): Cannot read V_BIOS


With the PCIe GeForce as the primary card (Radeon fails as secondary):
The PCIe GeForce works fine. With a default configuration, the radeon driver
fails to detect the correct VideoRam or any attached monitors. If I force these
values with MonitorLayout and VideoRam, it gets a bit further but then can't
verify the modelines, so again ends up without any useable modes. Again, the
problems would seem to start around:
(II) Attempted to read BIOS 128KB from /sys/bus/pci/devices/0000:07:01.0/rom:
got 0KB
Requesting insufficient memory window!: start: 0x62000000 end: 0x620fffff size
0x8000000
(EE) Cannot find empty range to map base to
(EE) RADEON(1): Cannot read V_BIOS
(--) RADEON(1): Chipset: "ATI Radeon 9250 5960 (AGP)" (ChipID = 0x5960)


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.1.1-47.5.fc6
xorg-x11-drv-nv-1.2.0-4.fc6
xorg-x11-drv-ati-6.6.3-1.fc6

Comment 1 Kevin R. Page 2007-02-08 16:07:52 UTC
Created attachment 147662 [details]
PCI Radeon set as the primary card (GeForce fails as secondary)

Comment 2 Kevin R. Page 2007-02-08 16:10:03 UTC
Created attachment 147663 [details]
PCIe GeForce as the primary card (Radeon fails as secondary)

Comment 3 Matěj Cepl 2007-02-09 11:52:44 UTC
I assume it is fresh installation with automatic configuration, right? Could you
attach your /etc/X11/xorg.conf as well, please?

Comment 4 Kevin R. Page 2007-02-09 12:18:25 UTC
Created attachment 147759 [details]
xorg.conf used when first two attachments were generated

It was a fresh install of FC6, then yum updated, though the xorg.conf attached
above was significantly tinkered with to try to get things to working (as you
can see from the commented options!). I was able to get the radeon as secondary
further along with MonitorLayout and VideoRam.

I can run  system-config-display --reconfig to create a clean xorg.conf and
generate some logs for that if it helps? However:

- on install I had to unpug the PCI radeon, or I was dropped down to text-mode
install. I suspect anaconda was mis-detecting - I saw something like "PCI card
detected" even though the PCIe card was set as primary. With just the PCIe
card, the graphical install worked fine. I'm afraid I don't have time to go
back and document this bug further at the moment - sorry.

- with the PCI radeon plugged back in, system-config-display failed to generate
a working xorg.conf, and did so in slightly wacky ways (not offering sensible
values for the second head monitor etc.). In hindsight, I'd guess this was
because it was having the same issues retreiving detected values from the
xserver as I was when doing it manually?

Comment 5 Kevin R. Page 2007-02-09 12:25:41 UTC
Also, I found this:
https://bugzilla.novell.com/show_bug.cgi?id=171453

but haven't yet had a chance to check whether their patch made it upstream, or
whether it's the same issue (though it has the "cannot read V_BIOS" similarity,
it may be a red herring).

Comment 6 Kevin R. Page 2007-02-09 18:00:57 UTC
The Novell bug entry references two fdo bugs.

The first is included in the source for xorg-x11-server-Xorg-1.1.1-47.5.fc6:
https://bugs.freedesktop.org/show_bug.cgi?id=6751

The second describes some quite major brokeness, which may be the root cause of
this bug, and a workaround involving saving the second video bios to disk:
https://bugs.freedesktop.org/show_bug.cgi?id=2597

I may try out the workaround mentioned next week.

Comment 7 Kevin R. Page 2007-02-15 17:43:00 UTC
I tried applying the patches from:
https://bugs.freedesktop.org/show_bug.cgi?id=2597#c37
(also attached, slightly modified, below)

I then booted the PC with the PCI Radeon set as primary, and dumped its V_BIOS:
dd if=/dev/mem of=/root/r9200.bios bs=65536 skip=12 count=1

I couldn't get the bios through /sys/devices/pci ... /rom

Next, I set the PCIe GeForce as the primary once more, and added:
Option      "BiosLocation" "file:/root/r9200.bios"
to the device section of the Radeon (xorg.conf also attached below).

Using the V_BIOS from file solves the problem for me - I can now use both heads
(and the Xorg.0.log shows [nearly!] everything being detected correctly).

So, there is definitely an issue reading the VBIOS of the secondary card. It may
be a mainboard BIOS bug. The patches I used allow a workaround. Could these be
applied, please?

https://bugs.freedesktop.org/show_bug.cgi?id=2597#c52
is insightful.

One caveat:
After a fresh boot, the Radeon correctly detects that there isn't a second head
attached, and sets the available modes correctly. On subsequent restarts of the
Xserver it gets this wrong - believes that there's a second head CRT, and
incorrectly sets available resolutions. Xorg logs attached below.
Forcing the correct configuration with:
 Option      "MonitorLayout" "TDMS,NONE"
works around this.

Comment 8 Kevin R. Page 2007-02-15 17:44:45 UTC
Created attachment 148123 [details]
Patch for xorg-x11-drv-ati package

Comment 9 Kevin R. Page 2007-02-15 17:45:56 UTC
Created attachment 148124 [details]
Patch for xorg-x11-server package

Comment 10 Kevin R. Page 2007-02-15 17:51:34 UTC
Created attachment 148126 [details]
Second patch to xorg-x11-server package

The code following the second hunk has changed from the version the original
bfo patch was made against - it looked ok to me to drop it in where I have, but
could do with more eyeballing (I have no previous familiarity with this code at
all!).

Comment 11 Kevin R. Page 2007-02-15 17:53:05 UTC
Created attachment 148127 [details]
Working xorg.conf with patched xserver

Comment 12 Kevin R. Page 2007-02-15 17:54:37 UTC
Created attachment 148128 [details]
Xorg.0.log after fresh boot - heads detected correctly

Option	    "MonitorLayout" "TDMS,NONE"
isn't used to force correct heads.

Comment 13 Kevin R. Page 2007-02-15 17:55:57 UTC
Created attachment 148129 [details]
Xorg.0.log following subsequent X restart - heads detected incorrectly

Option	    "MonitorLayout" "TDMS,NONE"
isn't used to force correct heads.

Comment 14 Kevin R. Page 2007-07-11 11:57:03 UTC
Re-tested with F7 (using the LiveCD - thank goodness I didn't upgrade!), and the
problem still exists. To be clear: I cannot use a second graphics card in my PC
- at all.

Furthermore, the patches to xorg-x11-server attached above no longer cleanly
apply - from the changelog it looks like there have been some changes around
VBIOS detection?

Bearing in mind the patches were slight modifications of someone elses work, I'm
not convinved I can safely re-model them with confidence.

I'll attach xorg.conf and logs below.

Comment 15 Kevin R. Page 2007-07-11 12:02:34 UTC
Created attachment 158938 [details]
xorg.conf: PCIe GeFore as primary card (Radeon fails as secondary)

radeon fails to load VBIOS correctly, so doesn't know available modes for the
monitor; thus it fails to configure/allocate the second head.

Comment 16 Kevin R. Page 2007-07-11 12:03:31 UTC
Created attachment 158939 [details]
Xorg.0.log: PCIe GeFore as primary card (Radeon fails as secondary)

radeon fails to load VBIOS correctly, so doesn't know available modes for the
monitor; thus it fails to configure/allocate the second head.

Comment 17 Kevin R. Page 2007-07-11 12:07:20 UTC
Created attachment 158941 [details]
xorg.conf: PCI radeon set as primary in BIOS (GeForce fails as secondary)

nv driver fails to load VBIOS correctly, so detects a VRAM size of 0kb; no
video modes are available, and the second head cannot be allocated.

Comment 18 Kevin R. Page 2007-07-11 12:08:15 UTC
Created attachment 158942 [details]
Xorg.0.log: PCI radeon set as primary in BIOS (GeForce fails as secondary)

nv driver fails to load VBIOS correctly, so detects a VRAM size of 0kb; no
video modes are available, and the second head cannot be allocated.

Comment 19 Kevin R. Page 2007-11-13 17:48:33 UTC
Still present in Fedora 8 (Live CD, then loading a custom Xorg.conf).

I realise there are lots of changes I don't fully understand going on in Xorg at
the moment: in the radeon driver, RandR, modesetting in the kernel; which may
make this a bad moment to fix the bug. If I hang out for F9 is anything working
its way through that might to solve this bug? I'm stuck on FC6 as it's the last
version which cleanly patches to keep both my monitors working.

Anyway, F8 fails to initialise the PCI card if the PCIe is primary, as before;
with the PCI card primary, the PCIe card fails to initialise correctly, but then
the PCI card also bombs out with:

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x81) [0x80cdee1]
1: [0x12d420]
2: /usr/bin/X(RRCrtcSetRotations+0x9) [0x81678a9]
3: /usr/bin/X(xf86RandR12SetRotations+0x6b) [0x80f893b]
4: /usr/bin/X(xf86CrtcScreenInit+0x9e) [0x80f35ae]
5: /usr/lib/xorg/modules//drivers/radeon_drv.so(RADEONScreenInit+0x17cd) [0x5263
1d]
6: /usr/bin/X(AddScreen+0x1ee) [0x806fb7e]
7: /usr/bin/X(InitOutput+0x225) [0x80a2b65]
8: /usr/bin/X(main+0x27b) [0x807032b]
9: /lib/libc.so.6(__libc_start_main+0xe0) [0x214390]
10: /usr/bin/X(FontFileCompleteXLFD+0x1f1) [0x806f831]

Fatal server error:
Caught signal 11.  Server aborting
disable montype: 3
(II) RADEON(0): RADEONRestoreMemMapRegisters() : 
(II) RADEON(0):   MC_FB_LOCATION   : 0x1fff0000
(II) RADEON(0):   MC_AGP_LOCATION  : 0x27ff2000
finished PLL2
finished PLL1
Entering Restore TV
Restore TV PLL
Restore TVHV
Restore TV Restarts
Restore Timing Tables
Restore TV standard
Leaving Restore TV




Comment 20 Kevin R. Page 2008-05-19 11:45:36 UTC
I'd like to test this with Fedora 9 but I'm falling at the first hurdle. Any
hints on how to configure this hardware setup these days?

i.e. two graphics cards, one PCIe, one PCI.

I just tried to create an xorg.conf with two Device sections with the relevant
BusID and drivers, and it seems to have locked the machine (from LiveCD).

Comment 21 Bug Zapper 2009-06-09 22:26:52 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 22 Bug Zapper 2009-07-14 16:48:25 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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