Created attachment 16982 [details] xorg configuration file I have a AMD64 with two pci-e graphics cards : Sapphire ATI HD 2600 XT Sapphire ATI HD 2600 Pro I'm running Fedora 9. Configuration of the second card fails. I tried without HPD option, with HPD swap, and HPD off, but the same result in any case. I uploaded the Xorg.0.log file, and the xorg.conf file. The xorg.conf contains a line about livna installation, but this driver has been removed before trying the radeonhd driver. Is there a workaround ?
Created attachment 16983 [details] Xorg log file
Access to secondary cards should still work. Maybe it broke somewhere along the way. I need to investigate this.
Your driver is from April, could you please fetch a new version from GIT and try again? I've tried dual card and didn't see those problems. I did have to boot with the option pci=rom and later on do: echo 1 > /sys/bus/pci/devices/<pci_device>/rom to enable access to the rom of the secondary card. (replace <pci_device> with the actual pci device address of the second card - in your case 0000:05:00:0). I still didn't get a secondary R6xx card to work. It seems that InitAsic isn't fully initializing things - an issue that still needs to be looked into.
I'm sorry but due to some compatibility problems with the motherboard (Asus M3A32-MVP Deluxe SAM2+), I decided to replace the whole thing : new motherboard and 2 NVidia cards. I'm afraid I can't help you with this anymore.
With the steps described in comment #3 i can access the BIOS on an R6xx card. Since the reporter no longer has the hardware there is no way to find out what went wrong.
I am having the same problem as the original poster. I have a x86_64 motherboard with an onboard Radeon HD 3200 GPU and a Radeon HD 2600 XT PCIE card: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics 02:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT] I'm using xorg-x11-drv-radeonhd-1.2.3-1.3.20081029git.fc9.x86_64 under Fedora 9. I configured the motherboard BIOS to use the onboard GPU as primary, since as I understand it that should work better. After booting the secondary GPU is disabled: 02:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Unknown device 0990 Flags: fast devsel, IRQ 10 Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M] Memory at fbdf0000 (64-bit, non-prefetchable) [disabled] [size=64K] I/O ports at d000 [disabled] [size=256] Expansion ROM at fbdc0000 [disabled] [size=128K] The suggestion to boot with "pci=rom" and then to execute "echo 1 > /sys/bus/pci/devices/0000:02:00.0/rom" did not enable the expansion ROM, although I believe the address changed slightly. When I try my default ServerLayout that attempts to use both cards, the second card fails to initialize with "rhdAtomGetTables: No AtomBios signature found". I will attach both the xorg.conf and the Xorg.log. Now I read somewhere about some PCI configuration commands I don't really understand. So I tried executing "setpci -s 02:00.0 ROM_ADDRESS=fbdc0001; setpci -s 02:00.0 COMMAND=3". This causes lspci to show the Expansion ROM as enabled. When I now try the dual card ServerLayout, the primary card now fails to initialize with "Cannot allocate 0 bytes of memory for BIOS image". The secondary card starts to initialize properly but ultimately fails with rhd_mc.c:671: RHDRestoreMC: Assertion '(RHDRegRead(rhdPtr, D1CRTC_CONTROL) & 0x1) != 0x1' failed I will attach the full Xorg.log for this attempt. Lastly I tried running two separate instances of X, one for each card using ServerLayouts with the appropriate IsolateDevice options. The result without the setpci magic above was uninformative, each card responded the same as it did jointly. After executing the setpci magic, though, the response to the IsolateDevice layouts differed from the joint layout. X on the primary card worked fine. X on the secondary card found the ATOM BIOS rom this time, but then failed with "No Video RAM detected." Presumably this is because the card was not ever POSTed? I'll attach the Xorg.logs
Created attachment 19983 [details] Second Poster's xorg.conf
Created attachment 19984 [details] Xorg.log initial failure
Created attachment 19985 [details] Xorg.log failure, both cards, after setpci magic
Created attachment 19986 [details] Xorg.log success, primary card, after setpci magic
Created attachment 19987 [details] Xorg.log failure, secondary card, after setpci magic
(In reply to comment #6) > > The suggestion to boot with "pci=rom" and then to execute "echo 1 > > /sys/bus/pci/devices/0000:02:00.0/rom" did not enable the expansion ROM, > although I believe the address changed slightly. I'm not sure why this isn't working for you. It is outside of the domain of X or the X driver, though. > > When I try my default ServerLayout that attempts to use both cards, the second > card fails to initialize with "rhdAtomGetTables: No AtomBios signature found". > I will attach both the xorg.conf and the Xorg.log. This indeed means that no ROM is found. > > Now I read somewhere about some PCI configuration commands I don't really > understand. So I tried executing "setpci -s 02:00.0 ROM_ADDRESS=fbdc0001; This enables to ROM. It doesn't mean that you will be able to read it out. > setpci -s 02:00.0 COMMAND=3". This causes lspci to show the Expansion ROM as > enabled. When I now try the dual card ServerLayout, the primary card now falis Don't do this! This enables the card. Thus the Xserver will assume it's primary and won't POST it any more. > to initialize with "Cannot allocate 0 bytes of memory for BIOS image". The > secondary card starts to initialize properly but ultimately fails with > > rhd_mc.c:671: RHDRestoreMC: Assertion '(RHDRegRead(rhdPtr, D1CRTC_CONTROL) & > 0x1) != 0x1' failed Not sure why you are seeing this. It's probably due to a non-POSTed card. > > I will attach the full Xorg.log for this attempt. > > Lastly I tried running two separate instances of X, one for each card using > ServerLayouts with the appropriate IsolateDevice options. The result without > the setpci magic above was uninformative, each card responded the same as it > did jointly. After executing the setpci magic, though, the response to the > IsolateDevice layouts differed from the joint layout. X on the primary card > worked fine. X on the secondary card found the ATOM BIOS rom this time, but > then failed with "No Video RAM detected." Presumably this is because the card > was not ever POSTed? I'll attach the Xorg.logs > That's what I also assume. I don't think what you see are driver issues. But in any case part of the PCI magic you did caused the second card to not be POSTed. Please retry and reopen in case there are still problems.
Created attachment 19996 [details] [review] Proposed Workaround. Instead of testing for IsPrimary() check if the RAM size is initialized. Please test if this workaround helps.
Hi, I tried the patch you supplied to check the videoRAM size. First, for the record, as we discussed I have to do manual setpci commands before running X to be able to get anywhere with my secondary card. The commands are: "setpci -s ..:.. ROM_ADDRESS=....0001 ; setpci -s ..:.. COMMAND=2". From a fresh boot, if I do the setpci commands and then try the patched radeonhd_drv with an xorg.conf containing active sections for both cards, then I am able to get both cards running together. This is the first time I've achieved that. However, if I exit X and then try the same thing again, it crashes. Looking at the log, it finds the wrong BIOS for the secondary card during the second execution. The first time X is run, the secondary card doesn't have its VRAM enabled, so the patch takes the correct path in rhdAtomInit(). But the second time X runs, the VRAM has already been enabled, so the legacy VBIOS path is taken for the secondary card, which causes radeonhd to find the BIOS for the primary card. That is presumably the root of the crash. If I understand correctly the problem is to find the correct BIOS image for the card, and in particular to know when to use the legacy VBIOS path in rhdAtomInit(). As I understand it, the legacy VBIOS path should work for the boot video device, so the question is how to determine if we are dealing with the boot video device. Without the patch, rhdAtomInit() uses xf86IsEntityPrimary() to decide whether to check the legacy VBIOS path. According to <http://www.x.org/archive/X11R6.8.1/doc/DESIGN9.html>, this is the right thing to do: "This function returns TRUE if the entity referenced by entityIndex is the primary display device (i.e., the one initialised at boot time and used in text mode)". But in practice, sometimes the Xserver is uncertain (I get "(!!) More than one possible primary device found" in Xorg.log), and sometimes it is just wrong--when using IsolateDevice for a multi-seat setup (separate X processes driving each card individually), Xserver only sees one card and flags it as Primary. At least that is the behavior with the package xorg-x11-server-Xorg-1.5.2-10.fc10.x86_64. A couple questions: (1) Should I log a bug on xfIsEntityPrimary() against Xserver? I'm not sure if that interface ever worked, since I'm new to this. The reference I found is rather old. (2) Is there any other way to determine whether a card is the boot video device? (3) Some code could be added to verify that the BIOS image file found matches the card being configured, and if not rhdAtomInit() could keep looking. (4) Can we use /sys/bus/pci/devices/..../rom? Lastly let me say I don't know anything about libpciaccess or whatever problems its integration into Xorg has caused, so I may not have things straight here. Thanks, Wayne
I have this problem too. The first card is AGP and the second one is PCI (selected as primary in BIOS). 01:00.0 VGA compatible controller: ATI Technologies Inc RV670PRO [Radeon HD 3850] 02:09.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5500] (rev a1) Tried with xorg-server-1.5.3 and xf86-video-radeonhd-1.2.4. xf86-video-nv was used for the nVidia card.
Hi, I have the same problem on my machine, I have 1 onboard card and the second is ATI RV610 card # lspci | grep VGA 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev a2) 02:00.0 VGA compatible controller: ATI Technologies Inc RV610 [Radeon HD 2400 XT] From Xorg.0.log : (II) RADEONHD(0): Unknown card detected: 0x94C1:0x1458:0x2190. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x94C1:0x1458:0x2190: <name of board> and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RV610 on an unidentified card (II) RADEONHD(0): FUNCTION: rhdMapMMIO (II) RADEONHD(0): Mapped IO @ 0xf5000000 to 0x7f24169a8000 (size 0x00010000) (II) RADEONHD(0): PCIE Card Detected (II) RADEONHD(0): FUNCTION: RHDAtomBiosFunc (II) RADEONHD(0): FUNCTION: rhdAtomInit (II) RADEONHD(0): Getting BIOS copy from PCI ROM (II) RADEONHD(0): FUNCTION: rhdAtomGetTables (EE) RADEONHD(0): rhdAtomGetTables: No AtomBios signature found (II) RADEONHD(0): Query for AtomBIOS Init: failed (II) RADEONHD(0): FUNCTION: RHDAtomBiosFunc (**) RADEONHD(0): Call to Analog TV Default Mode failed (II) RADEONHD(0): FUNCTION: rhdGetVideoRamSize (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Using only 262144kB of the total 4194303kB. (--) RADEONHD(0): VideoRAM: 262144 kByte (II) RADEONHD(0): FUNCTION: RHDDRIPreInit (II) RADEONHD(0): Direct rendering turned off by default. Use Option "DRI" to enable. I found out that even if I run the following command : # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/rom X fails to run on the RV610 card, and I can't even 'cat' the content of the rom, but if I run the following commands : # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/enable # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/rom I am able to run X on the second card Sagi.
> but if I run the following commands : > # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/enable > # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/rom > I am able to run X on the second card This is correct. The first one enables the card the second one enables reading from the ROM bar. Maybe libpciaccess should do this for us...
(In reply to comment #17) > > but if I run the following commands : > > # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/enable > > # echo 1 > /sys/bus/pci/devices/0000\:02\:00.0/rom > > > I am able to run X on the second card > > This is correct. The first one enables the card the second one enables reading > from the ROM bar. Maybe libpciaccess should do this for us... It does. Libpciaccess provides a function to enable the card and a function to copy the PCI ROM. Its routine to copy the PCI ROM enables the ROM, copies the ROM, then finishes up by disabling the ROM (as it should). The AtomBIOS init code, if it fails to get the BIOS at the legacy VBIOS position, calls rhdDoReadPCIBios() in rhd_driver.c to attempt a load from the PCI ROM. That calls the libpciaccess function to copy the PCI ROM (assuming compilation of radeonhd with libpciaccess). Since libpciacess does the enable and disable of the PCI ROM one shouldn't need to do it manually. I am not sure though if the libpciaccess PCI enable function is called - I am still looking through the radeonhd/xserver initialisation code to locate that. There may be other issues with reading the PCI ROM at kernel level. My kernel log, for example, contains: radeon 0000:01:00.0: Invalid ROM contents whenever the X server accesses the PCI ROM (or I do through a little utility I have written to access the ROM with libpciaccess). To see this message one must run the v. latest Linux kernel (2.6.29 release candidate). It's generated when the PCI ROM is detected by the kernel to have an invalid PCI ROM marker (0x55 0xAA as the first two bytes). I would be interested to know if anyone else is seeing such messages in the kernel logs (though probably unlikely since it requires a yet unreleased kernel!). Michael.
(In reply to comment #18) > I am not sure though if the libpciaccess PCI enable function is called - I am > still looking through the radeonhd/xserver initialisation code to locate that. Nah. The radeonhd driver does not call pci_device_enable(). In contrast, the ati driver does call pci_device_enable(). I intend to write a patch, but want to first study and better understand the initialisation code of both the ati and radeonhd drivers. I suspect there are other issues involved. Michael.
Hello, I wanted to provide an update on this issue after six months. I have an x86_64 motherboard with an onboard Radeon HD 3200 GPU and a Radeon HD 2600 XT PCIE card: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics 02:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT] I am pleased to report xorg-x11-drv-radeonhd-1.2.5-2.8.20090411git.fc11.x86_64 from Fedora 11 works fine in dual head mode. No more problems initializing the secondary card, and no need for echo 1 > /sys/.../enable to activate the card. However, I have a dual seat setup, and so I need to be able to run two separate X processes, one controlling each card. With this, I still have difficulty. The problem seems to be a poor interaction between the X server option IsolateDevice and rhdAtomInit() in radeonhd. If I understand correctly, rhdAtomInit() uses xf86IsEntityPrimary() to determine whether it is dealing with the boot video card or a secondary video card. For the boot video card case, it executes a branch to get the BIOS copy from the legacy VBIOS location; in the other case it calls RHDReadPCIBios() to read the BIOS from PCI config space. The problem is that when IsolateDevice is used to tell the X server to only access one video card, then xf86IsEntityPrimary() seems to always return true. In the case of the secondary video card, rhdAtomInit() then treats it as a boot video card and ends up retreiving the BIOS of the wrong card. I was able to work around this by adding an option to radeonhd to force rhdAtomInit() into the RHDReadPCIBios() branch and using that option on the secondary card. However, that seems ugly, and I'm pretty much at the limit of my knowledge here. So what is the proper resolution to this problem? Should xf86IsEntityPrimary() behave differently when IsolateDevice is specified? Or should rhdAtomInit() use some other logic to determine whether a card is the boot card? Thanks very much, Wayne Whitney
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component. Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Closing due to lack of response. Please reopen and move to the Driver/Radeon component if this issue persists with xf86-video-ati
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.