I have a Radeon 7200 AGP and a Radeon 7000 PCI card and when I enable dri, the machine completely locks up. Starting with just either of the cards works fine. The problem only appears when I try to use both. Dump to console from X: [root@chronos xf86-video-ati]# X X Window System Version 7.1.1 Release Date: 12 May 2006 X Protocol Version 11, Revision 0, Release 7.1.1 Build Operating System: Fedora Core 7 Red Hat, Inc. Current Operating System: Linux chronos.drzeus.cx 2.6.18-1.2784.fc6 #1 SMP Thu Oct 12 18:49:59 EDT 2006 i686 Build Date: 01 December 2006 Build ID: xorg-x11-server 1.1.1-54.fc7 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sun Dec 3 22:59:34 2006 (==) Using config file: "/etc/X11/xorg.conf" dlopen: /usr/lib/xorg/modules/fonts/libtype1.so: undefined symbol: Type1RegisterFontFileFunctions (EE) Failed to load /usr/lib/xorg/modules/fonts/libtype1.so (EE) Failed to load module "type1" (loader failed, 7) (**) RADEON(0): RADEONPreInit (**) RADEON(1): RADEONPreInit (**) RADEON(0): RADEONScreenInit c8000000 0 (**) RADEON(0): Map: 0xc8000000, 0x02000000 (**) RADEON(0): RADEONSave (**) RADEON(0): RADEONSaveMode(0x905a290) (**) RADEON(0): Read: 0x0000003c 0x000301f7 0x00000000 (**) RADEON(0): Read: rd=60, fd=503, pd=3 (**) RADEON(0): RADEONSaveMode returns 0x905a290 (**) RADEON(0): DRI New memory map param (**) RADEON(0): RADEONInitMemoryMap() : (**) RADEON(0): mem_size : 0x02000000 (**) RADEON(0): MC_FB_LOCATION : 0xc9ffc800 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): RADEONModeInit() 1360x768 85.50 1360 1424 1536 1792 768 771 777 795 (24,32) +H +V 1360x768 85.50 1360 1424 1536 1792 768 771 777 795 (24,32) +H +V (**) RADEON(0): Pitch = 11534512 bytes (virtualX = 1360, displayWidth = 1408) (**) RADEON(0): dc=8550, of=17100, fd=380, pd=2 (**) RADEON(0): TMDS_PLL from 6a4 to a1b (**) RADEON(0): RADEONInit returns 0x905ac40 (**) RADEON(0): RADEONRestoreMode() (**) RADEON(0): RADEONRestoreMemMapRegisters() : (**) RADEON(0): MC_FB_LOCATION : 0xc9ffc800 (**) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (**) RADEON(0): Map Changed ! Applying ... (**) RADEON(0): Map applied, resetting engine ... (**) RADEON(0): Updating display base addresses... (**) RADEON(0): Memory map updated. (**) RADEON(0): Programming CRTC1, offset: 0x00000000 (**) RADEON(0): Wrote: 0x0000003c 0x0001017c 0x00000000 (0x0000a700) (**) RADEON(0): Wrote: rd=60, fd=380, pd=1 (**) RADEON(0): GRPH_BUFFER_CNTL from 20207c7c to 20137c7c (**) RADEON(0): RADEONSaveScreen(0) (**) RADEON(0): Setting up initial surfaces (**) RADEON(0): Initializing fb layer (**) RADEON(0): Setting up accel memmap (**) RADEON(0): Initializing backing store (**) RADEON(0): DRI Finishing init ! (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): GRPH_BUFFER_CNTL from 20207c7c to 20137c7c (**) RADEON(0): Setting up final surfaces (**) RADEON(0): Initializing Acceleration (**) RADEON(0): EngineInit (32/32) (**) RADEON(0): Pitch for acceleration = 176 (**) RADEON(0): EngineRestore (32/32) (**) RADEON(0): Initializing DPMS (**) RADEON(0): Initializing Cursor (**) RADEON(0): Initializing color map (**) RADEON(0): Initializing DGA (**) RADEON(0): Initializing Xv
Created attachment 7947 [details] xorg.conf Xorg.0.log is unfortunately empty.
(In reply to comment #1) > > Xorg.0.log is unfortunately empty. Please try mount -o remount,sync <filesystem containing /var/log/Xorg.*.log> before starting X.
Created attachment 7962 [details] Xorg.0.log Here you go. This time I also got these extra lines to the console: (**) RADEON(0): RADEONScreenInit finished (**) RADEON(1): RADEONScreenInit d0000000 0
Created attachment 8000 [details] Log of initialization failure
Created attachment 8001 [details] Log of good initialization but exit failure
Created attachment 8002 [details] Log of initialization and then good exit
Created attachment 8003 [details] xorg.conf for two X800XL
Hi! I experience the same problems as Pierre, but with two PCI-E cards (X800XL). I have no problem if I only use one card at a time. With both cards activated in my xorg.conf, I experience strange things : - Sometimes, it will initialize both screens at the good resolutions/frequencies (I can verify this on my monitors), but fail to launch the window manager. - Sometimes, it will load X, where dri works great on both screens at the same time (only tested with glxgears so far), but crash on exiting X. - Sometime, everything is ok : launching X and exiting it. It is quite sad that it is erratic as when I can launch X with DRI on both cards (totally random : 50% probably as far as I observed), it works excellently (thanks for the so good work on free acceleration to the DRI project). I hope I don't abuse posting this on this bugreport, but my problem is really similar to Pierre's one (except that sometimes, X will get launched). I also join my logs and xorg.conf. Otherwise, if it is of any help, let me know if I should install dri cvs (or git, I don't know which one you use) to test patched version when there will be. I am definately willing to help testing.
Just in order to give a precision (reading my message again made me understand it was not clear) : as in Pierre's case, when X doesn't get launched, the computer hard locks.
*poke* Any tests we can perform to pinpoint the problem?
(In reply to comment #8) > It is quite sad that it is erratic as when I can launch X with DRI on both cards > (totally random : 50% probably as far as I observed), it works excellently I didn't think this was even supposed to work yet, so consider yourself very lucky when it does. :}
Would it be possible to get it working on at least one of the cards? Or is that as difficult as getting it running on both?
(In reply to comment #12) > Would it be possible to get it working on at least one of the cards? Or is that > as difficult as getting it running on both? I think it should be fine on one screen only (modulo AIGLX maybe see bug 9339). The problem is that like most drivers, radeon currently enables the DRI when the "dri" X server module is loaded, there's no direct way to enable it on one screen but disable it on the other. I've been meaning to introduce Option "DRI" for this but kept being preempted by more important stuff. As a workaround, you could try causing the DRI to get disabled on one screen via options that can't be satisfied, e.g. Option "GARTSize" with very large or small values.
Still locks up, I'm afraid. I get this, so DRI should be disabled for the second card: (EE) RADEON(1): Illegal GART size: 512 MB I also tried disabling AIGLX, but that didn't help.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
(In reply to comment #14) > Still locks up, I'm afraid. I get this, so DRI should be disabled for the > second > card: > > (EE) RADEON(1): Illegal GART size: 512 MB > > I also tried disabling AIGLX, but that didn't help. > Hi there! Sorry for not having answered earlier, but personnal problems have kept me off this problem for some time... ... this morning, I saw there was a quite recent packet for x11-drm on Gentoo (20070314) that I tried at once... ... what I can say for myself is that with this one, using an illegal AGPGartSize (eg 256, 512, 3000 for what I tested) on the card where I need opengl the least made X.org launch without hard-locking the machine... but the display on the no-dri screen (a merfedfb of two monitors on one PCI-E card) is totally corrupted... so much it is not usable... though the screen on the second card works ok, dri included (it serves me as an mythfrontend)... ... so, is there any specific AGPGartSize you could advice me to use, not to get this corruption? Other than that, I have been testing the new drm module for a few hours and have to say that, without using AGPGartSize (not to get the borking of my screen), this one seems to be more stable for the, strange I have to confess (two cards, with a mergedfb pseudo xinerama on one of them, and a third monitor for mythtv), use I have of it :) I still have random lockup, either on X startup or exit, but it happens a lot less... I would say everything goes ok between 3 times out of 4 or 4 times out of 5... and when it works, it is the only way I have to use, at the same time, MergedXinerama and not have mplayer detect the wrong size for fullscreen (as the only mode it can tweak fullscreen size detection is opengl mode... when in XV mode, it persists to detect the size of one of the crts on the other card... as do every fullscreen app I use on the second card... but for mplayer, the only satisfactory workaround for me is with the opengl fullscreen output)... So really wonder if there is a way we can hope this bug be solved... opengl can solve many problems (like the fullscreen bug with fullscreen apps size detection on a second card when mergedfb pseudo-xinerama is used on another, which I still have to report)... and I assure you that this erratic bug is really rare and that everything works really good when X gets to be launched... I remember you said that it is no even supposed to work yet, but it is even more encouraging as it does yet quite excellently (except for the lockups, rarest as I said)... In fact, those erratic lockups on exiting are the only thing that prevent me to keep it as is, because I do all my maintenance outside of X on the console, and I must be able to switch in and out of X without things locking up in the middle of an emerge... it already works but "only" needs to be, at least a bit more, stable... Please let us know how we could be of any help... I dream so much of having a dual Metisse desktop with an opengl mythtv on a third screen (or at least my actual fvwm, plus opengl mythtv and the nice transitions) :D
is this still an issue with kms?
No idea. My dual head days are behind me and the machine in question is long since scrapped. :)
Closing then, thanks.
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.