Bug 9231

Summary: dri with two cards locks up
Product: xorg Reporter: Pierre Ossman <pierre-bugzilla>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED INVALID QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high    
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
xorg.conf
none
Xorg.0.log
none
Log of initialization failure
none
Log of good initialization but exit failure
none
Log of initialization and then good exit
none
xorg.conf for two X800XL none

Description Pierre Ossman 2006-12-03 14:02:34 UTC
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
Comment 1 Pierre Ossman 2006-12-03 14:07:25 UTC
Created attachment 7947 [details]
xorg.conf

Xorg.0.log is unfortunately empty.
Comment 2 Michel Dänzer 2006-12-04 03:17:45 UTC
(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.
Comment 3 Pierre Ossman 2006-12-04 11:58:27 UTC
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
Comment 4 Aefron 2006-12-07 08:37:52 UTC
Created attachment 8000 [details]
Log of initialization failure
Comment 5 Aefron 2006-12-07 08:38:50 UTC
Created attachment 8001 [details]
Log of good initialization but exit failure
Comment 6 Aefron 2006-12-07 08:39:31 UTC
Created attachment 8002 [details]
Log of initialization and then good exit
Comment 7 Aefron 2006-12-07 08:40:55 UTC
Created attachment 8003 [details]
xorg.conf for two X800XL
Comment 8 Aefron 2006-12-07 08:41:33 UTC
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.
Comment 9 Aefron 2006-12-08 01:50:22 UTC
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.
Comment 10 Pierre Ossman 2006-12-15 03:41:56 UTC
*poke*

Any tests we can perform to pinpoint the problem?
Comment 11 Michel Dänzer 2006-12-16 03:58:50 UTC
(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. :}
Comment 12 Pierre Ossman 2006-12-17 04:51:12 UTC
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?
Comment 13 Michel Dänzer 2006-12-19 03:37:35 UTC
(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.
Comment 14 Pierre Ossman 2006-12-21 22:20:50 UTC
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.
Comment 15 Daniel Stone 2007-02-27 01:35:00 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 16 Aefron 2007-03-18 22:28:03 UTC
(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
Comment 17 Alex Deucher 2010-10-19 15:49:07 UTC
is this still an issue with kms?
Comment 18 Pierre Ossman 2010-10-20 02:17:50 UTC
No idea. My dual head days are behind me and the machine in question is long since scrapped. :)
Comment 19 Julien Cristau 2010-10-20 05:42:28 UTC
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.