|Summary:||Second graphics card isn't correctly detected (V_BIOS?)|
|Product:||[Fedora] Fedora||Reporter:||Kevin R. Page <redhat-bugzilla>|
|Component:||xorg-x11-server||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED WONTFIX||QA Contact:||David Lawrence <dkl>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-14 16:48:25 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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.