Leif Delgass wrote:
> On Fri, 5 Jul 2002, Jens Owen wrote:
>
>
>>Leif Delgass wrote:
>>
>>
>>>On Fri, 5 Jul 2002, Jens Owen wrote:
>>>
>>>[snip]
>>>
>>>
>>>
>>>>However, I think you may be tickling a latent bug in the DRI. It's
>>>>possible that all the other drives have just avoided this bug so far.
>>>>
>>>>I looked at DRICloseScreen and I don't see that the DRIClipNotify
>>>>wrapper is being removed. There are other unwraps missing as well.
>>>>
>>>>Can you send me a back trace from a static debuggable server? Let me
>>>>know if you need help building this.
>>>>
>>>>
>>>Could you tell me how to build a static server or point me to a HOWTO?
>>>
>>
>>The xc/config/cf/host.def in the DRI tree is setup to easily modified to
>>build a debuggable server. Attached is a copy of a modified host.def
>>file I used for debugging an i810 problem. You'll probably need to add
>>the mach64 driver to these options.
>>
>
> OK, I'll try this. I think you're right that we need to add the
> GlxBuiltIn.. option for mach64.
If my memory serves me, that's just for 3D clients, and it doesn't work
anymore...so I wouldn't worry about that option. However, you will want
to add mach64 to the other driver lists in this file.
>
>>>Meanwhile, here's a backtrace from the X server built from the branch. It
>>>looks like the ClipNotify wrapper is being called when pDRIPriv is null,
>>>though I'm not sure why I wouldn't have run into this before...
>>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>>>1732 if(pDRIPriv->wrap.ClipNotify) {
>>>(gdb) bt
>>>#0 DRIClipNotify (pWin=0x85d3a60, dx=0, dy=0) at dri.c:1732
>>>#1 0x080c9009 in MapWindow (pWin=0x85d3a60, client=0x81d56a8) at window.c:2864
>>>#2 0x080c5ee8 in InitRootWindow (pWin=0x85d3a60) at window.c:522
>>>#3 0x080bf39c in main (argc=4, argv=0xbffff9d4, envp=0xbffff9e8) at main.c:439
>>>#4 0x40072647 in __libc_start_main (main=0x80bee9c <main>, argc=4,
>>> ubp_av=0xbffff9d4, init=0x806cc08 <_init>, fini=0x8174c80 <_fini>,
>>> rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff9cc)
>>> at ../sysdeps/generic/libc-start.c:129
>>>(gdb) info locals
>>>pWin = 0x85d3a60
>>>pScreen = 0x85d3748
>>>pDRIPriv = 0x0
>>>pDRIDrawablePriv = 0x0
>>>
>>
>>Yes, it looks like the DRI initialization process was started, causing
>>the DRI wrappers to be put in place; then, something caused DRI
>>initialization to fail, but the failure handling code does not remove
>>the wrappers.
>>
>>I believe I need to unwrap the DRI routines in DRICloseScreen. I'd like
>>to fix this case and ask you to test with what you've got since it's
>>hard to test these unusual failure cases when everythings working properly.
>>
>>It's still curious no other drivers have had this problem. Either
>>nobody else has gone done these failure cases, or I'm barking up the
>>wrong tree.
>>
>
> It's pretty easy to test if you just change the return value of the
> driver's drm init function to return non-zero. For example, I tried this
> in the r128 driver in r128_do_init_cce (changed the last line to return
> -1), and it suffers the same problem (the backtrace was the same).
Yes, it's easy for force specific failures; but I don't think developers
and users have been hitting these cases in normal testing scenarios.
Otherwise, we'd have caught this during the 3 years this extensions been
in use.
>>Can you verify that we are indeed calling DRICloseScreen by putting a
>>breakpoint at that routine and sending me a backtrace at that point?
>>
>
> I know it's called because I see the messages in the X log about removing
> the signal handler, kernel context, SAREA, etc. It's called as part of
> the DRI driver specific CloseScreen (ATIDRICloseScreen) when the kernel
> init fails (which is after DRIFinishScreenInit is called). In fact, the
> entire X init seems to work without a hitch (I see all the normal messages
> in the X log after "Direct rendering disabled" up to XINPUT) until the
> root window is initialized.
Okay, try the attached patch. I think I'll do more than this, but it
would be great if you could test just this, first.
--
/\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
--- xc/programs/Xserver/GL/dri/dri.c.jens Fri Jul 5 13:07:43 2002
+++ xc/programs/Xserver/GL/dri/dri.c Fri Jul 5 16:27:11 2002
@@ -417,11 +417,14 @@
DRICloseScreen(ScreenPtr pScreen)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+ DRIInfoPtr pDRIInfo;
drmContextPtr reserved;
int reserved_count;
if (pDRIPriv && pDRIPriv->directRenderingSupport) {
+ pDRIInfo = pDRIPriv->pDriverInfo;
+
if (pDRIPriv->wrap.AdjustFrame) {
ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
@@ -477,6 +480,27 @@
drmClose(pDRIPriv->drmFD);
+ /* Unwrap DRI Functions */
+ if (pDRIInfo->wrap.ValidateTree) {
+ pScreen->ValidateTree = pDRIPriv->wrap.ValidateTree;
+ }
+ if (pDRIInfo->wrap.PostValidateTree) {
+ pScreen->PostValidateTree = pDRIPriv->wrap.PostValidateTree;
+ }
+ if (pDRIInfo->wrap.WindowExposures) {
+ pScreen->WindowExposures = pDRIPriv->wrap.WindowExposures;
+ }
+ if (pDRIInfo->wrap.CopyWindow) {
+ pScreen->CopyWindow = pDRIPriv->wrap.CopyWindow;
+ }
+ if (pDRIInfo->wrap.ClipNotify) {
+ pScreen->ClipNotify = pDRIPriv->wrap.ClipNotify;
+ }
+ if (pDRIInfo->wrap.AdjustFrame) {
+ ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+ pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
+ }
+
xfree(pDRIPriv);
pScreen->devPrivates[DRIScreenPrivIndex].ptr = NULL;
}
