On Tue, May 4, 2010 at 11:21 PM, Pierre-Loup A. Griffais <[email protected]> wrote: > Tiago, > > 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. 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 >
Secundary card is not posted by BIOS so driver has to handle initialization. This is radeon bug which might be fixed already. I remember similar bug report a few months ago. As a workaround you could try to switch primary card in BIOS if the driver for the current primary card knows how to initialize unposted card. > 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? > > Thanks, > - Pierre-Loup > > On 05/04/2010 10:28 AM, Pierre-Loup A. Griffais wrote: >> >> Tiago, >> >> This commit fixes the SW cursor with several screens, so the "multi-card >> case" >> is more or less the point of the change. Can you be more specific about >> the >> problems you're having and your testing environment? Do you have the SW >> cursor >> forced on? >> >> Removing the dependency on devPrivates from this layer is way outside the >> scope >> of this patch. >> >> Thanks, >> - Pierre-Loup >> >> On 05/04/2010 07:10 AM, Tiago Vignatti wrote: >>> >>> Pierre and Peter, >>> >>> >>> commit 518f3b189b6c8aa28b62837d14309fd06163ccbb >>> Author: Pierre-Loup A. Griffais<[email protected]> >>> Date: Wed Apr 21 16:46:17 2010 -0700 >>> >>> mi: don't thrash resources when displaying the software cursor >>> across screens >>> >>> >>> This commit break my system in a very bizarre way that I cannot kill the >>> X server, neither use it anymore. I can reproduce it only when I set two >>> video >>> cards by the server. >>> >>> I haven't checked the logic behind the commit to see exactly what's going >>> wrong. But I'd guess maybe your forgetting multi-card case? Also, we >>> don't >>> want privates mechanism in these common layers, so you could cook a >>> commit >>> without it. >>> >>> >>> Cheers, >>> >>> Tiago >> _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
