On Fri, Oct 25, 2002 at 01:15:15PM +0200, Michel Dänzer wrote:
>On Don, 2002-10-24 at 14:25, David Dawes wrote:
>> On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote:
>> >On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
>> >> On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
>> >> > > That certainly shouldn't be needed for shared entities. Where exactly
>> >> > > was it crashing ?
>> >> >
>> >> > XAA dereferences pScrn->pScreen to track the state of shared entities.
>> >> > RADEONScreenInit() calls other radeon driver functions which call
>> >> > info->accel->Sync(), but the driver independent code only sets pScrn->pScreen
>> >> > after ScreenInit(). Boom.
>> >>
>> >> A backtrace would be useful.
>>
>> The backtrace would be useful for showing the exact call sequence leading
>> to the SEGV, and may help in determining if the problem should be fixed
>> in a different way.
>
>Kevin Puetz sent me this one:
>
>0x081952ca in XAAStateWrapSync (pScrn=0x8870a80) at xaaStateChange.c:313
>313 GET_STATEPRIV_PSCRN(pScrn);
>(gdb) bt
>#0 0x081952ca in XAAStateWrapSync (pScrn=0x8870a80) at xaaStateChange.c:313
>#1 0x080fdae5 in RADEONLoadPalette (pScrn=0x8870a80, numColors=256,
>indices=0x88bc9e8, colors=0x88bcdf0, pVisual=0x8886d88) at radeon_driver.c:2429
>#2 0x0829dabb in CMapRefreshColors (pmap=0x88b6b80, defs=256, indices=0x88bc9e8) at
>xf86cmap.c:619
>#3 0x0829d1c7 in CMapReinstallMap (pmap=0x88b6b80) at xf86cmap.c:493
>#4 0x0829d127 in CMapSetDGAMode (index=0, num=0, dev=0x0) at xf86cmap.c:470
>#5 0x08287082 in DGAShutdown () at xf86DGA.c:475
>#6 0x0826ee91 in ddxGiveUp () at xf86Init.c:1082
>#7 0x0826efaf in AbortDDX () at xf86Init.c:1145
>#8 0x0830a9a8 in AbortServer () at utils.c:436
>#9 0x0830c65f in FatalError (f=0x8795d40 "Caught signal %d. Server aborting\n") at
>utils.c:1402
>#10 0x08289c81 in xf86SigHandler (signo=11) at xf86Events.c:1085
>#11 0x40079518 in sigaction () from /lib/libc.so.6
>#12 0x080fdae5 in RADEONLoadPalette (pScrn=0x8870a80, numColors=256,
>indices=0x88bc9e8, colors=0x88bcdf0, pVisual=0x8886d88) at radeon_driver.c:2429
>#13 0x0829dabb in CMapRefreshColors (pmap=0x88b6b80, defs=256, indices=0x88bc9e8) at
>xf86cmap.c:619
>#14 0x0829d1c7 in CMapReinstallMap (pmap=0x88b6b80) at xf86cmap.c:493
>#15 0x0829cf0c in CMapInstallColormap (pmap=0x88b6b80) at xf86cmap.c:418
>#16 0x0829c726 in xf86HandleColormaps (pScreen=0x8886008, maxColors=256,
>sigRGBbits=8, loadPalette=0x80fda88 <RADEONLoadPalette>, setOverscan=0, flags=3) at
>xf86cmap.c:196
>#17 0x080ff0c9 in RADEONScreenInit (scrnIndex=0, pScreen=0x8886008, argc=1,
>argv=0xbffffd14) at radeon_driver.c:2966
>#18 0x082ec94a in AddScreen (pfnInit=0x80fe0ac <RADEONScreenInit>, argc=1,
>argv=0xbffffd14) at main.c:768
>#19 0x0826e893 in InitOutput (pScreenInfo=0x885a4a0, argc=1, argv=0xbffffd14) at
>xf86Init.c:819
>#20 0x082ebbc7 in main (argc=1, argv=0xbffffd14, envp=0xbffffd1c) at main.c:380
So it's crashing in RADEONLoadPalette, not in XAA. I imagine it's this
line:
#ifdef XF86DRI
if (info->CPStarted) DRILock(pScrn->pScreen, 0);
#endif
>> >What's the problem with setting this pointer, anyway?
>>
>> If pScrn->pScreen must be dereferenced before the end of ScreenInit, then
>> you need to set it. The driver independent code can't set it before
>> it already does (it isn't allocated yet),
>
>But ScreenInit() seems to have both pScreen and pScrn from the beginning?
Yes, but the XFree86 common layer code (InitOutput) doesn't. It calls
AddScreen(), which allocates pScreen and then calls the driver's
ScreenInit. AddScreen() is DIX code that doesn't know about pScrn.
The driver's ScreenInit is the first function that knows about and sees
both pScreen and pScrn.
>> so if the driver needs it, it has to do it itself. I think the problem
>> isn't setting this pointer, but making sure that setting it isn't just
>> covering up some other problem.
>
>Curious if you see something.
It seems that some drivers call DRILock/Unlock like this so that they
can do it before ScreenInit is finished:
DRIUnlock(screenInfo.screens[pScrn->scrnIndex]);
I don't think it matters much either way, but initialising pScrn->pScreen
in ScreenInit is shorter.
David
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
