ports/132041: Broken Intel video driver

[Paul B. Mahol]

On 4/28/09, Giorgos Keramidas <keramida at freebsd.org> wrote:
> The following reply was made to PR ports/132041; it has been noted by GNATS.
>
> From: Giorgos Keramidas <keramida at freebsd.org>
> To: Arthur Barlow <arthurbarlow at earthlink.net>
> Cc: bug-followup at freebsd.org
> Subject: Re: ports/132041: Broken Intel video driver
> Date: Tue, 28 Apr 2009 23:26:17 +0300
>
>  On Tue, 28 Apr 2009 22:05:51 +0300, Giorgos Keramidas
> <keramida at freebsd.org> wrote:
>  >   http://lists.freedesktop.org/archives/xorg/2009-April/045117.html
>  >
>  > I've just updated my local port to 2.7.0 a few minutes ago and attached
>  > the patch of the update to this message.  The 2.7.0 release of the Intel
>  > video driver seems a lot more stable so far.  At least, I haven't been
>  > able to crash it by switching desktops while a video is playing or by
>  > clicking to the context menu of a media player, or by covering a media
>  > player with another window.
>
>  I spoke too soon. I managed to crash xf86-video-intel-2.7.0 too, through
>  mplayer again (by minimizing and restoring the mplayer window a few
>  times inside GNOME).  The backtrace this was was:
>
>    root at kobe:/root# gdb /usr/local/bin/Xorg /var/gdm/Xorg.core
>    [...]
>    #0  0x2860a5e7 in kill () at kill.S:2
>    2       RSYSCALL(kill)
>    [New Thread 28701140 (LWP 100170)]
>    (gdb) bt
>    #0  0x2860a5e7 in kill () at kill.S:2
>    #1  0x2851b3f7 in _raise (sig=6) at
> /usr/src/lib/libthr/thread/thr_sig.c:185
>    #2  0x2860916a in abort () at /usr/src/lib/libc/stdlib/abort.c:65
>    #3  0x285ef696 in __assert (func=0xbfbfe7a4 "\006", file=0x3 <Address 0x3
> out of bounds>, line=0,
>        failedexpr=0x286d0664 "bo_fake->block->bo == &bo_fake->bo") at
> /usr/src/lib/libc/gen/assert.c:54
>    #4  0x286cd5d3 in drm_intel_fake_reloc_and_validate_buffer () from
> /usr/local/lib/libdrm_intel.so.1
>    #5  0x286cd52b in drm_intel_fake_reloc_and_validate_buffer () from
> /usr/local/lib/libdrm_intel.so.1
>    #6  0x286cd52b in drm_intel_fake_reloc_and_validate_buffer () from
> /usr/local/lib/libdrm_intel.so.1
>    #7  0x286cd90d in drm_intel_fake_bo_exec () from
> /usr/local/lib/libdrm_intel.so.1
>    #8  0x286cb53e in drm_intel_bo_exec () from
> /usr/local/lib/libdrm_intel.so.1
>    #9  0x2881843a in intel_batch_flush () from
> /usr/local/lib/xorg/modules/drivers//intel_drv.so
>    #10 0x28823c9f in I830BlockHandler () from
> /usr/local/lib/xorg/modules/drivers//intel_drv.so
>    #11 0x08167890 in AnimCurScreenBlockHandler ()
>    #12 0x08133318 in compBlockHandler ()
>    #13 0x08089808 in BlockHandler ()
>    #14 0x0812177e in WaitForSomething ()
>    #15 0x081daba0 in AnyClientsWriteBlocked ()
>    #16 0x081dbd2c in ?? ()
>    #17 0x081d0438 in __JCR_LIST__ ()
>    #18 0x2873d5b0 in ?? ()
>    #19 0x0000000c in ?? ()
>    #20 0xbfbfeab8 in ?? ()
>    #21 0x08127b59 in Xalloc ()
>    #22 0x081d0438 in __JCR_LIST__ ()
>    #23 0x3c910800 in ?? ()
>    #24 0x3c9a7cc0 in ?? ()
>    #25 0xbfbfed48 in ?? ()

?? are mistery here, perhaps order of port upgrading dri libdrm and
Mesa ports is
important when buiding new X11 stuff server?

>    #26 0x08085d1d in Dispatch ()
>    Previous frame inner to this frame (corrupt stack?)
>    (gdb) q
>
>  This was with libdrm-2.4.9 from the Ports tree.
>
> _______________________________________________
> freebsd-x11 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>


-- 
Paul