Bug 16292

Actually the timeout doesn't matter, the problem is that the ioctl returns EINVAL... is there any corresponding kernel output? If not, is there any if you write 1 to /sys/module/drm/parameters/debug before reproducing the problem? Can you get a backtrace of the X server when the ioctl fails?

Oh, and are you using the DRM kernel modules from drm Git or those included in the kernel?

BTW, is MPX making sure software cursor rendering is never done from a SIGIO handler? That's not supported and could cause these symptoms.

On Wed, Jun 11, 2008 at 03:43:54AM -0700, bugzilla-daemon@freedesktop.org wrote:
> --- Comment #3 from Michel Dänzer <michel@tungstengraphics.com>  2008-06-11 03:43:53 PST ---
> BTW, is MPX making sure software cursor rendering is never done from a SIGIO
> handler? That's not supported and could cause these symptoms.

No, shouldn't happen. If we sw-render the cursors during SIGIO, timeouts are
the least of our problems.

Created attachment 17070 [details]
syslog with debug enabled (tail -f /var/log/syslog > syslog.out)

drm/drivers, server, everything from git.

without debug enabled, the only message appearing is:
[ 4893.520000] [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held  0 owner da1d9100 da1d9100

Breakpoint 1, RADEONWaitForIdleCP (pScrn=0x826a948) at radeon_commonfuncs.c:706
706                 xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
(gdb) bt
#0  RADEONWaitForIdleCP (pScrn=0x826a948) at radeon_commonfuncs.c:706
#1  0xb77727e8 in XAAGetImage (pDraw=0x89cc7f8, sx=0, sy=0, w=486, h=383, 
    format=2, planemask=4294967295, pdstLine=0xa5cca008 "") at xaaInit.c:262
#2  0xb77c527b in cwGetImage (pSrc=0x89cc7f8, x=0, y=0, w=486, h=383, 
    format=2, planemask=4294967295, pdstLine=0xa5cca008 "") at cw.c:354
#3  0x08152de2 in miSpriteGetImage (pDrawable=0x89cc7f8, sx=0, sy=0, w=486, 
    h=383, format=2, planemask=4294967295, pdstLine=0xa5cca008 "")
    at misprite.c:321
#4  0xb7a2c257 in __glXDRIbindTexImage (baseContext=0x84a8030, buffer=8414, 
    glxPixmap=0x89ccd60) at glxdri.c:488
#5  0xb7a17a27 in __glXDisp_BindTexImageEXT (cl=0x84aeb4c, pc=0x89c5518 "F")
    at glxcmds.c:1540
#6  0xb7a19168 in __glXDisp_VendorPrivate (cl=0x84aeb4c, 
    pc=0x89c550c "\233\020\006") at glxcmds.c:2255
#7  0xb7a1e1aa in __glXDispatch (client=0x84a8fc8) at glxext.c:492
#8  0x0808c712 in Dispatch () at dispatch.c:448
#9  0x08071ed4 in main (argc=1, argv=0xbfb40cf4, envp=0xbfb40cfc) at main.c:415


Full backtrace:

(gdb) bt full
#0  RADEONWaitForIdleCP (pScrn=0x826a948) at radeon_commonfuncs.c:706
        ret = -22
        info = (RADEONInfoPtr) 0x826ae88
        RADEONMMIO = (
    unsigned char *) 0xb78c1000 <Address 0xb78c1000 out of bounds>
        i = 0
        __FUNCTION__ = "RADEONWaitForIdleCP"
#1  0xb77727e8 in XAAGetImage (pDraw=0x89cc7f8, sx=0, sy=0, w=486, h=383, 
    format=2, planemask=4294967295, pdstLine=0xa5cca008 "") at xaaInit.c:262
        infoRec = (XAAInfoRecPtr) 0x829fa20
        pScreen = (ScreenPtr) 0x8275f58
        infoRec = (XAAInfoRecPtr) 0x829fa20
        pScrn = (ScrnInfoPtr) 0x826a948
#2  0xb77c527b in cwGetImage (pSrc=0x89cc7f8, x=0, y=0, w=486, h=383, 
    format=2, planemask=4294967295, pdstLine=0xa5cca008 "") at cw.c:354
        pScreen = (ScreenPtr) 0x8275f58
        pBackingDrawable = (DrawablePtr) 0x89cc7f8
        src_off_x = 0
        src_off_y = 0
#3  0x08152de2 in miSpriteGetImage (pDrawable=0x89cc7f8, sx=0, sy=0, w=486, 
    h=383, format=2, planemask=4294967295, pdstLine=0xa5cca008 "")
    at misprite.c:321
        pScreen = (ScreenPtr) 0x8275f58
        pScreenPriv = (miSpriteScreenPtr) 0x829f670
        pDev = (DeviceIntPtr) 0x0
        pCursorInfo = (miCursorInfoPtr) 0x84d38c8
#4  0xb7a2c257 in __glXDRIbindTexImage (baseContext=0x84a8030, buffer=8414, 
    glxPixmap=0x89ccd60) at glxdri.c:488
        pitch = 1944
        data = (void *) 0xa5cca008
        pRegion = (RegionPtr) 0x0
        pixmap = (PixmapPtr) 0x89cc7f8
        bpp = 4
        override = 0
        texname = 8
        format = 32993
        type = 5121
        pScreen = (ScreenPtr) 0x8275f58
        driDraw = (__GLXDRIdrawable *) 0x89ccd60
        screen = (__GLXDRIscreen * const) 0x83a4ed0
        __func__ = "__glXDRIbindTexImage"
#5  0xb7a17a27 in __glXDisp_BindTexImageEXT (cl=0x84aeb4c, pc=0x89c5518 "F")
    at glxcmds.c:1540
        req = (xGLXVendorPrivateReq *) 0x89c550c
        client = (ClientPtr) 0x84a8fc8
        context = (__GLXcontext *) 0x84a8030
        pGlxDraw = (__GLXdrawable *) 0x89ccd60
        drawId = 4194374
        buffer = 8414
        error = -1214169736
#6  0xb7a19168 in __glXDisp_VendorPrivate (cl=0x84aeb4c, 
    pc=0x89c550c "\233\020\006") at glxcmds.c:2255
        req = (xGLXVendorPrivateReq *) 0x89c550c
        vendorcode = 1330
        proc = (
    __GLXdispatchVendorPrivProcPtr) 0xb7a1791a <__glXDisp_BindTexImageEXT>
#7  0xb7a1e1aa in __glXDispatch (client=0x84a8fc8) at glxext.c:492
        rendering = 0 '\0'
        stuff = (xGLXSingleReq *) 0x89c550c
        opcode = 16 '\020'
        proc = (
    __GLXdispatchSingleProcPtr) 0xb7a1910f <__glXDisp_VendorPrivate>
        cl = (__GLXclientState *) 0x84aeb4c
        retval = 0
#8  0x0808c712 in Dispatch () at dispatch.c:448
        clientReady = (int *) 0x85bdff8
        result = 0
        client = (ClientPtr) 0x84a8fc8
        nready = 0
        icheck = (HWEventQueuePtr *) 0x824f3f0
        start_tick = 780
#9  0x08071ed4 in main (argc=1, argv=0xbfb40cf4, envp=0xbfb40cfc) at main.c:415
        i = 1
        j = 2
        k = 2
        xauthfile = 0x0
        alwaysCheckForInput = {0, 1}

Created attachment 17071 [details] [review]
Switch to X server DRI context for GetImage

Thanks for the information. Does this xserver patch fix it?

yep, patch fixes it. I still get the timeouts, but it doesnt lock up anymore.
Thanks.

(In reply to comment #8)
> yep, patch fixes it. I still get the timeouts, but it doesnt lock up anymore.

Weird. Did you revert your driver workaround before testing? Are you still getting messages like

[drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held  0 owner da1d9100 da1d9100

in the kernel output?

> --- Comment #9 from Michel Dänzer <michel@tungstengraphics.com>  2008-06-12 00:29:21 PST ---
> Weird. Did you revert your driver workaround before testing? Are you still
> getting messages like
> 
> [drm:radeon_cp_idle] *ERROR* radeon_cp_idle called without lock held, held  0
> owner da1d9100 da1d9100
> 
> in the kernel output?

Sorry, I should have been more clear: I still notice about 1 sec between
releasing the button and the window updating, but no error is printed.
My hack is reverted. With it I get the printed error.

(In reply to comment #10)
> Sorry, I should have been more clear: I still notice about 1 sec between
> releasing the button and the window updating, but no error is printed.

Could be XAA suckiness, is it better with EXA?

> My hack is reverted. With it I get the printed error.

Huh, I'm still confused then. Which error exactly?

Also, does the ioctl still fail with XAA? If so, is the backtrace still the same?

> Could be XAA suckiness, is it better with EXA?
yes, works fine now. thanks.

> Huh, I'm still confused then. Which error exactly?
nevermind, can't reproduce it now.

EXA:
- without your patch: no problems, no errors in Xorg.log, no perceived
timeouts.
- without your patch: no problems, no errors in Xorg.log, no perceived
timeouts

XAA:
- without your patch: the infinite loop as reported in comment #1.
- without your patch, with my "return;": error messages as reported in comment #1

- with your patch: no error messages in the Xorg.log, but a perceived timeout
  of ~1 sec between resizing and the actual update. Since no error is printed,
  this timeout is not fatal like without the patch.
- with your patch, with my "return;": no error messages, but a perceived
  timeout of ~1 sec between resizing and the actual update. Since no error is
  printed, this timeout is not fatal like without the patch.

One thing worth noting is that with XAA, gnome applications don't display much
more beyond the background colours until resized. gnome-calculator for example
only shows a grey and a white rectangle, no buttons etc. xterm doesn't always
render properly either, leaving half the window white. gnome-calculator
doesn't accept mouse clicks on the buttons. 
with EXA, that seems to be fine.

Do you want a syslog for any of those situations?

What matters is that the ioctl no longer fails with the patch with XAA.

XAA is known to be broken with compiz without Option "XaaNoOffscreenPixmaps".

Based on your previous comment, I'll assume that the patch does indeed fix the problem and pushed it, see below. Leaving the bug open though and making it a blocker for xserver 1.5, as this is a regression from 1.4.

commit 23b55a61f89f69454a3b0e3413b1f07d5fdf43aa
Author: Michel Dänzer <michel@tungstengraphics.com>
Date:   Fri Jun 13 11:13:56 2008 +0200

    AIGLX/DRI1: Switch to server context for calling pScreen->GetImage.

Cherry picked (more or less) into server-1.5-branch, closing.