multi-card breakage

[Pierre-Loup A. Griffais]

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