Patch for crashing intel server

Patch for crashing intel server

[Bas Wijnen]

Hello,

My X server was crashing when playing video, and I wrote a patch to fix
it.  Please find the background and the patch at
http://bugs.debian.org/724944 .

Thanks,
Bas

Re: Patch for crashing intel server

[Chris Wilson]

On Fri, Oct 11, 2013 at 09:24:54PM +0200, Bas Wijnen wrote:
> Hello,
> 
> My X server was crashing when playing video, and I wrote a patch to fix
> it.  Please find the background and the patch at
> http://bugs.debian.org/724944 .

The patch is a shotgun solution, putting NULL pointer checks where the
pointer is explicitly not allowed to be NULL. I need an actual
stacktrace to find the root cause.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Bas Wijnen]

[-- Attachment #1.1: Type: text/plain, Size: 894 bytes --]

On Sat, Oct 12, 2013 at 09:46:14PM +0100, Chris Wilson wrote:
> On Fri, Oct 11, 2013 at 09:24:54PM +0200, Bas Wijnen wrote:
> > Hello,
> > 
> > My X server was crashing when playing video, and I wrote a patch to fix
> > it.  Please find the background and the patch at
> > http://bugs.debian.org/724944 .
> 
> The patch is a shotgun solution, putting NULL pointer checks where the
> pointer is explicitly not allowed to be NULL. I need an actual
> stacktrace to find the root cause.
> -Chris

Sure thing; you can find it attached.  Of course it shows when the
segfault is triggered, not when the data became NULL.  And that should
be fixed, because even though the server doesn't crash with the patch,
it also doesn't play video.

If you need any more information (like debug statements in the
set_pixmap_private?), please let me know how I can generate it.

Thanks,
Bas

[-- Attachment #1.2: xorg.gdb-log --]
[-- Type: text/plain, Size: 7760 bytes --]

#0  0xb758f424 in __kernel_vsyscall ()
#1  0xb719380f in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0xb7196cc3 in __GI_abort () at abort.c:90
#3  0xb77574a9 in OsAbort () at ../../os/utils.c:1299
#4  0xb7630d07 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT)
    at ../../../../hw/xfree86/common/xf86Init.c:1063
#5  0xb7630da3 in AbortDDX (error=error@entry=EXIT_ERR_ABORT)
    at ../../../../hw/xfree86/common/xf86Init.c:1107
#6  0xb775cc41 in AbortServer () at ../../os/log.c:767
#7  0xb775d6be in FatalError (
    f=f@entry=0xb7785084 "Caught signal %d (%s). Server aborting\n")
    at ../../os/log.c:908
#8  0xb7754d84 in OsSigHandler (signo=11, sip=0xbfbe0f0c, unused=0xbfbe0f8c)
    at ../../os/osinit.c:147
#9  <signal handler called>
#10 0xb6f26d79 in intel_pixmap_tiled (pixmap=0xb8945808)
    at ../../../src/uxa/intel.h:138
#11 I915DisplayVideoTextured (scrn=0xb83f2f08, adaptor_priv=0xb83eed70, 
    id=808596553, dstRegion=0xbfbe14a8, width=352, height=288, 
    video_pitch=176, video_pitch2=352, src_w=352, src_h=288, drw_w=384, 
    drw_h=288, pixmap=0xb8425d98) at ../../../src/uxa/i915_video.c:156
#12 0xb6f22215 in I830PutImageTextured (scrn=0xb83f2f08, src_x=0, src_y=0, 
    drw_x=1308, drw_y=192, src_w=352, src_h=288, drw_w=384, drw_h=288, 
    id=808596553, buf=0xb3140000 <Address 0xb3140000 out of bounds>, 
    width=352, height=288, sync=0, clipBoxes=0xbfbe14a8, data=0xb83eed70, 
    drawable=0xb88fad78) at ../../../src/uxa/intel_video.c:1584
#13 0xb764877c in xf86XVPutImage (client=0xb8906010, pDraw=0xb88fad78, 
    pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, src_w=352, src_h=288, 
    drw_x=0, drw_y=0, drw_w=384, drw_h=288, format=0xb840ccd0, 
    data=0xb3140000 <Address 0xb3140000 out of bounds>, sync=0, width=352, 
    height=288) at ../../../../hw/xfree86/common/xf86xv.c:1827
#14 0xb769304c in XvdiPutImage (client=client@entry=0xb8906010, 
    pDraw=0xb88fad78, pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, 
    src_w=352, src_h=288, drw_x=0, drw_y=0, drw_w=384, drw_h=288, 
    image=image@entry=0xb840ccd0, 
    data=0xb3140000 <Address 0xb3140000 out of bounds>, sync=0, 
    width=width@entry=352, height=288) at ../../Xext/xvmain.c:673
#15 0xb7694648 in ProcXvShmPutImage (client=0xb8906010)
    at ../../Xext/xvdisp.c:1025
#16 0xb7696dae in ProcXvDispatch (client=0xb8906010)
    at ../../Xext/xvdisp.c:1212
#17 0xb75ed35d in Dispatch () at ../../dix/dispatch.c:432
#18 0xb75db38a in main (argc=13, argv=0xbfbe1774, envp=0xbfbe17ac)
    at ../../dix/main.c:298
#0  0xb758f424 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb719380f in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = <optimized out>
        resultvar = <optimized out>
        pid = -1221525504
        selftid = 29720
#2  0xb7196cc3 in __GI_abort () at abort.c:90
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0xbfbe0db0, 
            sa_sigaction = 0xbfbe0db0}, sa_mask = {__val = {3078486656, 
              3073441792, 171515904, 3076194304, 3076196648, 5, 3078438944, 
              3076120729, 3076197088, 3071376880, 1, 5, 0, 0, 0, 0, 0, 0, 0, 
              3076259256, 0, 0, 0, 3071717608, 0, 0, 0, 3078438912, 1, 
              3078475476, 3078475380, 3076146208}}, sa_flags = -1216480640, 
          sa_restorer = 0xb7196b80 <__GI_abort>}
        sigs = {__val = {32, 0 <repeats 31 times>}}
#3  0xb77574a9 in OsAbort () at ../../os/utils.c:1299
No locals.
#4  0xb7630d07 in ddxGiveUp (error=error@entry=EXIT_ERR_ABORT)
    at ../../../../hw/xfree86/common/xf86Init.c:1063
        i = <optimized out>
#5  0xb7630da3 in AbortDDX (error=error@entry=EXIT_ERR_ABORT)
    at ../../../../hw/xfree86/common/xf86Init.c:1107
        i = <optimized out>
#6  0xb775cc41 in AbortServer () at ../../os/log.c:767
No locals.
#7  0xb775d6be in FatalError (
    f=f@entry=0xb7785084 "Caught signal %d (%s). Server aborting\n")
    at ../../os/log.c:908
        args = 0xbfbe0ee4 "\v"
        args2 = 0xbfbe0ee4 "\v"
        beenhere = 1
#8  0xb7754d84 in OsSigHandler (signo=11, sip=0xbfbe0f0c, unused=0xbfbe0f8c)
    at ../../os/osinit.c:147
        unused = 0xbfbe0f8c
        sip = 0xbfbe0f0c
        signo = 11
#9  <signal handler called>
No symbol table info available.
#10 0xb6f26d79 in intel_pixmap_tiled (pixmap=0xb8945808)
    at ../../../src/uxa/intel.h:138
No locals.
#11 I915DisplayVideoTextured (scrn=0xb83f2f08, adaptor_priv=0xb83eed70, 
    id=808596553, dstRegion=0xbfbe14a8, width=352, height=288, 
    video_pitch=176, video_pitch2=352, src_w=352, src_h=288, drw_w=384, 
    drw_h=288, pixmap=0xb8425d98) at ../../../src/uxa/i915_video.c:156
        ms3 = <optimized out>
        s5 = <optimized out>
        tiling = <optimized out>
        pbox = 0xbfbe14a8
        nbox_total = 0
        nbox_this_time = 1
        dxo = 1308
        dyo = 192
        pix_xoff = -1308
        pix_yoff = -192
        target = 0xb8945808
#12 0xb6f22215 in I830PutImageTextured (scrn=0xb83f2f08, src_x=0, src_y=0, 
    drw_x=1308, drw_y=192, src_w=352, src_h=288, drw_w=384, drw_h=288, 
    id=808596553, buf=0xb3140000 <Address 0xb3140000 out of bounds>, 
    width=352, height=288, sync=0, clipBoxes=0xbfbe14a8, data=0xb83eed70, 
    drawable=0xb88fad78) at ../../../src/uxa/intel_video.c:1584
        adaptor_priv = 0xb83eed70
        dstPitch = 176
        dstPitch2 = 352
        dstBox = {x1 = 1308, y1 = 192, x2 = 1692, y2 = 480}
        crtc = 0xb83e8930
        top = 0
        left = 0
        npixels = 352
        nlines = 288
#13 0xb764877c in xf86XVPutImage (client=0xb8906010, pDraw=0xb88fad78, 
    pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, src_w=352, src_h=288, 
    drw_x=0, drw_y=0, drw_w=384, drw_h=288, format=0xb840ccd0, 
    data=0xb3140000 <Address 0xb3140000 out of bounds>, sync=0, width=352, 
    height=288) at ../../../../hw/xfree86/common/xf86xv.c:1827
        portPriv = 0xb83ecde8
        WinRegion = {extents = {x1 = 1308, y1 = 192, x2 = 1692, y2 = 480}, 
          data = 0x0}
        ClipRegion = {extents = {x1 = 1308, y1 = 192, x2 = 1692, y2 = 480}, 
          data = 0x0}
        WinBox = {x1 = 1308, y1 = 192, x2 = 1692, y2 = <optimized out>}
        ret = <optimized out>
        clippedAway = 0
#14 0xb769304c in XvdiPutImage (client=client@entry=0xb8906010, 
    pDraw=0xb88fad78, pPort=0xb840ce58, pGC=0xb89206d8, src_x=0, src_y=0, 
    src_w=352, src_h=288, drw_x=0, drw_y=0, drw_w=384, drw_h=288, 
    image=image@entry=0xb840ccd0, 
    data=0xb3140000 <Address 0xb3140000 out of bounds>, sync=0, 
    width=width@entry=352, height=288) at ../../Xext/xvmain.c:673
No locals.
#15 0xb7694648 in ProcXvShmPutImage (client=0xb8906010)
    at ../../Xext/xvdisp.c:1025
        shmdesc = 0xb8932e98
        pDraw = 0xb88fad78
        pPort = 0xb840ce58
        pImage = 0xb840ccd0
        pGC = 0xb89206d8
        status = <optimized out>
        size_needed = <optimized out>
        i = <optimized out>
        width = 352
        height = 288
        stuff = 0xb891f0b8
#16 0xb7696dae in ProcXvDispatch (client=0xb8906010)
    at ../../Xext/xvdisp.c:1212
        stuff = 0xb891f0b8
#17 0xb75ed35d in Dispatch () at ../../dix/dispatch.c:432
        clientReady = 0xb85d0d88
        result = <optimized out>
        client = 0xb8906010
        nready = 0
        icheck = 0xb77e1438 <checkForInput>
        start_tick = 1540
#18 0xb75db38a in main (argc=13, argv=0xbfbe1774, envp=0xbfbe17ac)
    at ../../dix/main.c:298
        i = <optimized out>
        alwaysCheckForInput = {0, 1}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Patch for crashing intel server

[Chris Wilson]

On Sun, Oct 13, 2013 at 05:49:04AM +0200, Bas Wijnen wrote:
> On Sat, Oct 12, 2013 at 09:46:14PM +0100, Chris Wilson wrote:
> > On Fri, Oct 11, 2013 at 09:24:54PM +0200, Bas Wijnen wrote:
> > > Hello,
> > > 
> > > My X server was crashing when playing video, and I wrote a patch to fix
> > > it.  Please find the background and the patch at
> > > http://bugs.debian.org/724944 .
> > 
> > The patch is a shotgun solution, putting NULL pointer checks where the
> > pointer is explicitly not allowed to be NULL. I need an actual
> > stacktrace to find the root cause.
> > -Chris
> 
> Sure thing; you can find it attached.  Of course it shows when the
> segfault is triggered, not when the data became NULL.  And that should
> be fixed, because even though the server doesn't crash with the patch,
> it also doesn't play video.

Ok, I can see the allocation failure that leads to the crash:

commit f9a18c9f38d09c145eb513ca989966dc135c1e9b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Oct 13 10:36:35 2013 +0100

    uxa: Check for allocation failure in i915 video
    
    For a large screen, we have to create a temporary surface for rendering
    the textured video. If this pixmap creation fails we may be left with a
    system memory only pixmap leading to a segfault.
    
    Reported-by: Bas Wijnen <wijnen@debian.org>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

However, that still leaveas the question as to how you ended up being
unable to allocate bo...

You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use
intel-gpu-overlay) and see if there is an object leak.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Bas Wijnen]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

On Sun, Oct 13, 2013 at 10:43:49AM +0100, Chris Wilson wrote:
> > > > My X server was crashing when playing video, and I wrote a patch to fix
> > > > it.  Please find the background and the patch at
> > > > http://bugs.debian.org/724944 .
> 
> Ok, I can see the allocation failure that leads to the crash:
> 
> commit f9a18c9f38d09c145eb513ca989966dc135c1e9b
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Sun Oct 13 10:36:35 2013 +0100

This does indeed stop the server from crashing, but actually makes the
problem worse: it used to play video for a few minutes and then crash
when trying.  With my patch it would play video for a few minutes and
then present black screens when trying.  With your patch, it presents
black screens from the start.

I must say I'm not entirely sure if the backtrace I sent you is a
"typical" case; I managed to crash it sooner than usual, so perhaps it
wasn't the bug that I triggered before.  It did stop the crashing
however.

> However, that still leaveas the question as to how you ended up being
> unable to allocate bo...
> 
> You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use
> intel-gpu-overlay) and see if there is an object leak.

I don't have enough knowledge about the internals to know how that
works.  I can see the file if I mount the debugfs, but what am I looking
for?

I don't seem to have intel-gpu-overlay on my system; does it make sense
to install it?  If so, where do I get it?

While looking for it I did find and try intel-gpu-time, and noticed that
it always reports the gpu 100% busy, even when running intel-gpu-time
sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
that normal?

Thanks,
Bas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Chris Wilson]

On Tue, Oct 15, 2013 at 03:46:08AM +0200, Bas Wijnen wrote:
> On Sun, Oct 13, 2013 at 10:43:49AM +0100, Chris Wilson wrote:
> > > > > My X server was crashing when playing video, and I wrote a patch to fix
> > > > > it.  Please find the background and the patch at
> > > > > http://bugs.debian.org/724944 .
> > 
> > Ok, I can see the allocation failure that leads to the crash:
> > 
> > commit f9a18c9f38d09c145eb513ca989966dc135c1e9b
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Sun Oct 13 10:36:35 2013 +0100
> 
> This does indeed stop the server from crashing, but actually makes the
> problem worse: it used to play video for a few minutes and then crash
> when trying.  With my patch it would play video for a few minutes and
> then present black screens when trying.  With your patch, it presents
> black screens from the start.

Start of video, or beginning of X?

I made two changes. The first to check for a failed GPU pixmap
allocation during video playback and the second to check for a failed
malloc during Screen initialisation.

Neither should be likely.
 
> I must say I'm not entirely sure if the backtrace I sent you is a
> "typical" case; I managed to crash it sooner than usual, so perhaps it
> wasn't the bug that I triggered before.  It did stop the crashing
> however.
> 
> > However, that still leaveas the question as to how you ended up being
> > unable to allocate bo...
> > 
> > You can watch /sys/kernel/debug/dri/0/i915_gem_objects (or just use
> > intel-gpu-overlay) and see if there is an object leak.
> 
> I don't have enough knowledge about the internals to know how that
> works.  I can see the file if I mount the debugfs, but what am I looking
> for?

An increase in the number of total objects and allocated bytes.
 
> I don't seem to have intel-gpu-overlay on my system; does it make sense
> to install it?  If so, where do I get it?

It just presents the same information, so not really important if you
are happy with catting the debugfs file.
 
> While looking for it I did find and try intel-gpu-time, and noticed that
> it always reports the gpu 100% busy, even when running intel-gpu-time
> sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
> that normal?

Hmm, looks like it should report correctly on i915.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Bas Wijnen]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > This does indeed stop the server from crashing, but actually makes the
> > problem worse: it used to play video for a few minutes and then crash
> > when trying.  With my patch it would play video for a few minutes and
> > then present black screens when trying.  With your patch, it presents
> > black screens from the start.
> 
> Start of video, or beginning of X?

Beginning of X.  After starting and logging in, I can play them for a
few minutes; afterwards it will crash.

> > I must say I'm not entirely sure if the backtrace I sent you is a
> > "typical" case; I managed to crash it sooner than usual, so perhaps it
> > wasn't the bug that I triggered before.  It did stop the crashing
> > however.
> > 
> > > However, that still leaveas the question as to how you ended up being
> > > unable to allocate bo...

I didn't check the backtrace myself, but when I wrote my shotgun-patch,
the problem was that pixmap_private was NULL; bo is in there, right?  So
at least in that case, it could never have allocated it, or at least it
couldn't store the pointer.

> > While looking for it I did find and try intel-gpu-time, and noticed that
> > it always reports the gpu 100% busy, even when running intel-gpu-time
> > sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
> > that normal?
> 
> Hmm, looks like it should report correctly on i915.

Due to unrelated problems (unbearable slowness) I switched from gnome to
xfce.  It does report 0% now.  It seems gnome keeps the gpu busy even if
it's not displaying anything...

Thanks,
Bas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Chris Wilson]

On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
> On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > > This does indeed stop the server from crashing, but actually makes the
> > > problem worse: it used to play video for a few minutes and then crash
> > > when trying.  With my patch it would play video for a few minutes and
> > > then present black screens when trying.  With your patch, it presents
> > > black screens from the start.
> > 
> > Start of video, or beginning of X?
> 
> Beginning of X.  After starting and logging in, I can play them for a
> few minutes; afterwards it will crash.

Still weird. Can you attach the Xorg.log from the black screen and/or crash.

> > > I must say I'm not entirely sure if the backtrace I sent you is a
> > > "typical" case; I managed to crash it sooner than usual, so perhaps it
> > > wasn't the bug that I triggered before.  It did stop the crashing
> > > however.
> > > 
> > > > However, that still leaveas the question as to how you ended up being
> > > > unable to allocate bo...
> 
> I didn't check the backtrace myself, but when I wrote my shotgun-patch,
> the problem was that pixmap_private was NULL; bo is in there, right?  So
> at least in that case, it could never have allocated it, or at least it
> couldn't store the pointer.

I doubt we failed to malloc the intel_pixmap, so the reason why the
intel_pixmap would be NULL is more likely due to failure to allocate the
GPU buffer object i.e. they are semantically interchangeable, an
attached intel_pixmap to a Pixmap implies we have a GPU bo. Similarly
checking for the intel_pixmap should be enough to assert that the GPU bo
exists.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Patch for crashing intel server

[Bas Wijnen]

[-- Attachment #1.1.1: Type: text/plain, Size: 1200 bytes --]

On Wed, Oct 16, 2013 at 04:22:43PM +0100, Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
> > On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > > > This does indeed stop the server from crashing, but actually makes the
> > > > problem worse: it used to play video for a few minutes and then crash
> > > > when trying.  With my patch it would play video for a few minutes and
> > > > then present black screens when trying.  With your patch, it presents
> > > > black screens from the start.
> > > 
> > > Start of video, or beginning of X?
> > 
> > Beginning of X.  After starting and logging in, I can play them for a
> > few minutes; afterwards it will crash.
> 
> Still weird. Can you attach the Xorg.log from the black screen and/or crash.

That took some time, because since I switched to xfce, it is a lot more
stable.  However, after running for a few days it still crashed when
trying to play a video.  The log is attached.

I would have attached a detailed backtrace as well, but unfortunately I
forgot to switch the core dump option on when switching from gdm to xdm,
so I don't have a core this time.

Thanks,
Bas

[-- Attachment #1.1.2: Xorg.0.log.old --]
[-- Type: application/x-trash, Size: 117224 bytes --]

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Patch for crashing intel server

[Chris Wilson]

On Wed, Oct 23, 2013 at 02:30:51AM +0200, Bas Wijnen wrote:
> On Wed, Oct 16, 2013 at 04:22:43PM +0100, Chris Wilson wrote:
> > On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
> > > On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > > > > This does indeed stop the server from crashing, but actually makes the
> > > > > problem worse: it used to play video for a few minutes and then crash
> > > > > when trying.  With my patch it would play video for a few minutes and
> > > > > then present black screens when trying.  With your patch, it presents
> > > > > black screens from the start.
> > > > 
> > > > Start of video, or beginning of X?
> > > 
> > > Beginning of X.  After starting and logging in, I can play them for a
> > > few minutes; afterwards it will crash.
> > 
> > Still weird. Can you attach the Xorg.log from the black screen and/or crash.
> 
> That took some time, because since I switched to xfce, it is a lot more
> stable.  However, after running for a few days it still crashed when
> trying to play a video.  The log is attached.
> 
> I would have attached a detailed backtrace as well, but unfortunately I
> forgot to switch the core dump option on when switching from gdm to xdm,
> so I don't have a core this time.

No worries, if you can run

addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215

that should give me the information needed to pinpoint the crash.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Patch for crashing intel server

[Bas Wijnen]

[-- Attachment #1.1: Type: text/plain, Size: 1424 bytes --]

On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote:
> No worries, if you can run
> 
> addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215
> 
> that should give me the information needed to pinpoint the crash.

$ addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79
0xf8215
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel.h:138
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/i915_video.c:156
/build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel_video.c:1584

Note that I'm running the unpatched Debian version again (so not with
your or my patch), which is why it was crashing.

In case you have different sources, here's some context for those lines:

intel.h:138 is
 static inline Bool intel_pixmap_tiled(PixmapPtr pixmap)
 {
>        return intel_get_pixmap_private(pixmap)->tiling != I915_TILING_NONE;
 }

i915_video.c:156 is
                /* front buffer, pitch, offset */
>		if (intel_pixmap_tiled(target)) {
			tiling = BUF_3D_TILED_SURFACE;

and intel_video.c:1584 is
        } else {
>               I915DisplayVideoTextured(scrn, adaptor_priv, id, clipBoxes,
		width, height, dstPitch, dstPitch2,
		src_w, src_h, drw_w, drw_h,
		pixmap);
	}

Thanks,
Bas

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Chris Wilson]

On Fri, Oct 25, 2013 at 05:46:53AM +0200, Bas Wijnen wrote:
> On Wed, Oct 23, 2013 at 09:28:28AM +0100, Chris Wilson wrote:
> > No worries, if you can run
> > 
> > addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79 0xf8215
> > 
> > that should give me the information needed to pinpoint the crash.
> 
> $ addr2line -e /usr/lib/xorg/modules/drivers/intel_drv.so -i 0xfcd79
> 0xf8215
> /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel.h:138
> /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/i915_video.c:156
> /build/xserver-xorg-video-intel-WbV7Z9/xserver-xorg-video-intel-2.21.15/build/src/uxa/../../../src/uxa/intel_video.c:1584
> 
> Note that I'm running the unpatched Debian version again (so not with
> your or my patch), which is why it was crashing.

Ah. Ok, but we still don't know how we end up in this situation. If you
apply the patch to prevent the crash here, can you please report what
the contents of /sys/kernel/debug/dri/0/i915_gem_objects is at the time
the video goes black?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Bug#724944: [Intel-gfx] Patch for crashing intel server

[Bas Wijnen]

Hi Chris,

I got a black screen while using your patch.
/sys/kernel/debug/dri/0/i915_gem_objects contents are shown below.  The first
time is while the video is running; the second after stopping it.  AFAICS,
there is no difference between them.

However, after starting a new video, there is a difference in active objects;
not sure if it is related (I don't really know what any of it means).  That is
the third one.

Thanks,
Bas

root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  0 [0] active objects, 0 [0] bytes
  131 [131] inactive objects, 34430976 [34430976] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound)
root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  0 [0] active objects, 0 [0] bytes
  131 [131] inactive objects, 34430976 [34430976] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (0 active, 30703616 inactive, 5922816 unbound)
root@star:/sys/kernel/debug/dri/0# cat i915_gem_objects 
220 objects, 36782080 bytes
131 [131] objects, 34430976 [34430976] bytes in gtt
  2 [2] active objects, 32768 [32768] bytes
  129 [129] inactive objects, 34398208 [34398208] bytes
49 unbound objects, 638976 bytes
1 purgeable objects, 4096 bytes
6 pinned mappable objects, 15884288 bytes
118 fault mappable objects, 27901952 bytes
536870912 [268435456] gtt total

Xorg: 217 objects, 36642816 bytes (32768 active, 30670848 inactive, 5922816 unbound)

Re: Patch for crashing intel server

[Chris Wilson]

On Sun, Nov 03, 2013 at 04:15:18PM +0100, Bas Wijnen wrote:
> Hi Chris,
> 
> I got a black screen while using your patch.
> /sys/kernel/debug/dri/0/i915_gem_objects contents are shown below.  The first
> time is while the video is running; the second after stopping it.  AFAICS,
> there is no difference between them.

Indeed, that scuppers my theory about it being an allocation failure to
GEM space exhaustion. I am not sure what else to suggest to explain why
it spontaneously fails to allocate that BO. You could try drm.debug=7,
but searching for the failure would be like hunting for a needle in a
haystack - and I'm not sure if we give any information as to how it
fails, nor does libdrm_intel have any such debug. You can try disabling
the uxa BO cache with Option "BufferCache" "false" and seeing if that
makes any difference.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre