Tiago,
On 05/19/2010 08:09 AM, Vignatti Tiago (Nokia-D/Helsinki) wrote:
Hi Pierre,
On Tue, May 04, 2010 at 10:21:55PM +0200, ext Pierre-Loup A. Griffais wrote:
I just reproduced something that sounds like what you're describing with
two R520 cards (one X screen per card) and the 'radeon' driver. However, it
seems unrelated to my change; that's what the hang looks like:
575 VGAGet(); (gdb) bt #0 VGAarbiterCreateGC (pGC=0x83ebab0) at
../../../../hw/xfree86/common/xf86VGAarbiter.c:575 #1 0x080777ba in
CreateGC (pDrawable=0x82d8d78, mask=<value optimized out>, pval=0xbffff534,
pStatus=0xbffff53c, gcid=0, client=0x81ffca8) at ../../dix/gc.c:647 #2
0x0819e612 in miDCMakeGC (pWin=0x82b5530) at ../../mi/midispcur.c:422 #3
0x0819e7c4 in miDCDeviceInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at
../../mi/midispcur.c:790 #4 0x081c48cf in miSpriteDeviceCursorInitialize
(pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/misprite.c:949 #5
0x08186364 in xf86DeviceCursorInitialize (pDev=0x83ebdf0,
pScreen=0x8263688) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:453 #6
0x081672ba in VGAarbiterDeviceCursorInitialize (pDev=0x83ebdf0,
pScreen=0x8263688) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:1035
#7 0x080a1e0c in miPointerDeviceInitialize (pDev=0x83ebdf0,
pScreen=0x8263688) at ../../mi/mipointer.c:283 #8 0x08087ed5 in
ActivateDevice (dev=0x83ebdf0, sendevent=1 '\001') at
../../dix/devices.c:477 #9 0x08088f08 in InitCoreDevices () at
../../dix/devices.c:610 #10 0x08066d18 in main (argc=1, argv=0xbffff8a4,
envp=0xbffff8ac) at ../../dix/main.c:255
The reason my change exposes this bug is that it creates a GC attached to
the second screen upfront. If I roll it back, I still get the same hang
after trying to move a SW cursor to the second screen of connecting an X
client to the second screen.
I'm still getting a very weird lock-up with your patch. I can get it even
with hw cursor. Seems not related at all with the log bellow when radeon POST
bios, so I guess your commit added a regression. Just reverting it solves
the problem - and sorry, I don't know this code in depth to start dig the
reason.
Multiple cards work fine on my end. All this change does is create a few GCs
and Pictures upfront on each X screen; I don't believe it sits at a level where
we can consider it's directly the cause of a system hang.
Can you provide more information regarding the issues you're having? What driver
are you using? Try single-stepping through miDCDeviceInitialize() when the
server starts and progressively break into more functions to determine where it
hangs with more accuracy. Also, if X is hung in the kernel because of an
interaction problem with the VGA-arbiter (as I still think that's the problem
you're having), using an SMP-capable setup should allow you to keep interacting
with the system after X hangs.
Thanks,
- Pierre-Loup
BTW, Peter did you test this patch there with multiple cards? I'd revert
this patch meanwhile (attached).
Looking at the X log, I see:
(II) RADEON(1): PCIE card detected (II) Loading sub module "int10" (II)
LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II)
RADEON(1): initializing int10 (EE) RADEON(1): Cannot read V_BIOS (3)
Input/output error (WW) RADEON(1): Failed to read PCI ROM! (II) RADEON(1):
Attempting to read un-POSTed bios
and in the kernel log:
[ 1240.582149] pci 0000:05:00.0: Invalid ROM contents
That means the VGA arbiter tried to switch VGA access to an un-posted
device, which is presumably the cause of the hang. It seems like the X
screen should fail ScreenInit() and get discarded after initializing int10
fails. Whatever the reason behind that is, the driver ought to fail more
gracefully.
In any case, I'm guessing you have similar spew in your logs?
no. My logs are "normal", without any apparent errors.
Thank you,
Tiago
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
