I'm not supporting NetBSD. Assign back to me if you reproduce this on Linux.

Hello:

linux-2.6.29.1 with intel driver 2.7rc2 as of commit: 10b5014c42dc055d9559ee112cc7a017e887d813 Not using KMS

Xorg from Debian experimental and the rest from Debian sid. This is xserver 1.5.99.902-1 with libdrm and libdrm-intel 2.4.5 and mesa 7.4. I have EXA acceleration with DRI disabled, Xorg log attached.

I'm having a very similar backtrace:
#0  0x00007fe1a41be105 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fe1a41bf623 in *__GI_abort () at abort.c:88
#2  0x00007fe1a41b7149 in *__GI___assert_fail (
    assertion=0x7fe1a2c10518 "pI830->batch_ptr != ((void *)0)",
    file=0x7fe1a2c105d1 "../../src/i830_batchbuffer.h", line=78,
    function=0x7fe1a2c10710 "intel_batch_emit_dword") at assert.c:78
#3  0x00007fe1a2bbf497 in I830EmitFlush (pScrn=<value optimized out>)
    at ../../src/i830_batchbuffer.h:78
#4  0x00007fe1a2bbf799 in I830Sync (pScrn=0x266bb10) at ../../src/i830_accel.c:191
#5  0x00007fe1a2bcd12d in I830LeaveVT (scrnIndex=<value optimized out>,
    flags=<value optimized out>) at ../../src/i830_driver.c:3406
#6  0x000000000046c20d in AbortDDX () at ../../../../hw/xfree86/common/xf86Init.c:1452
#7  0x00000000004f749d in AbortServer () at ../../os/log.c:407
#8  0x00000000004f7b40 in FatalError (f=0x57d410 "Caught signal %d.  Server aborting\n")
    at ../../os/log.c:532
#9  0x0000000000483b89 in xf86SigHandler (signo=11)
    at ../../../../hw/xfree86/common/xf86Events.c:387
#10 <signal handler called>
#11 0x00007fe1a299a630 in drm_intel_fake_reloc_and_validate_buffer (bo=0x7022230)
    at ../../../libdrm/intel/intel_bufmgr_fake.c:1274
---Type <return> to continue, or q <return> to quit---
#12 0x00007fe1a299a65e in drm_intel_fake_reloc_and_validate_buffer (bo=0x732b270)
    at ../../../libdrm/intel/intel_bufmgr_fake.c:1259
#13 0x00007fe1a299aa32 in drm_intel_fake_bo_exec (bo=0x732b270, used=504, cliprects=0x0,
    num_cliprects=0, DR4=-1) at ../../../libdrm/intel/intel_bufmgr_fake.c:1354
#14 0x00007fe1a2bc015f in intel_batch_flush (pScrn=0x266bb10, flushed=<value optimized out>)
    at ../../src/i830_batchbuffer.c:200
#15 0x00007fe1a2beddac in I965DisplayVideoTextured (pScrn=0x266bb10, pPriv=0x297acb8,
    id=<value optimized out>, dstRegion=0x7fffae676b90, width=<value optimized out>,
    height=<value optimized out>, video_pitch=320, x1=0, y1=0, x2=41943040, y2=31457280,
    src_w=<value optimized out>, src_h=<value optimized out>, drw_w=<value optimized out>,
    drw_h=<value optimized out>, pPixmap=0x2992f50) at ../../src/i965_video.c:1127
#16 0x00007fe1a2bde149 in I830PutImage (pScrn=0x266bb10, src_x=<value optimized out>,
    src_y=<value optimized out>, drw_x=<value optimized out>, drw_y=<value optimized out>,
    src_w=<value optimized out>, src_h=480, drw_w=<value optimized out>,
    drw_h=<value optimized out>, id=842094169,
    buf=0x7fe18c6d6000 "T_jmnmjeQ69OW^dX=%\037(*)-169<?CEGKRWSG7+')7KchS7)+7?DDCDFF===>??@ABDFHKE<8BUgk_PE=9322344420268847=<60/5@ILF>987300+(&)+,--...0434112/(&%&'()+./135678:;>ADGIKPW^dghmrsty\177\203\201\203\206\202oUC=@Mb}\200\201\202\201\200~}zzywvtqnigdb"..., width=640, height=480, sync=1,
    clipBoxes=0x7fffae676b90, data=0x297acb8, pDraw=0x7325290) at ../../src/i830_video.c:2562
#17 0x000000000048ffc6 in xf86XVPutImage (client=<value optimized out>, pDraw=0x7325290,
    pPort=0x297c408, pGC=<value optimized out>, src_x=-20064, src_y=-19920, src_w=640,
---Type <return> to continue, or q <return> to quit---
    src_h=13632, drw_x=0, drw_y=0, drw_w=<value optimized out>, drw_h=<value optimized out>,
    format=0x297c140,
    data=0x7fe18c6d6000 "T_jmnmjeQ69OW^dX=%\037(*)-169<?CEGKRWSG7+')7KchS7)+7?DDCDFF===>??@ABDFHKE<8BUgk_PE=9322344420268847=<60/5@ILF>987300+(&)+,--...0434112/(&%&'()+./135678:;>ADGIKPW^dghmrsty\177\203\201\203\206\202oUC=@Mb}\200\201\202\201\200~}zzywvtqnigdb"..., sync=1,
    width=<value optimized out>, height=<value optimized out>)
    at ../../../../hw/xfree86/common/xf86xv.c:1768
#18 0x00007fe1a3ae4c4b in ProcXvShmPutImage (client=0x78ed820) at ../../Xext/xvdisp.c:1171
#19 0x000000000044cea4 in Dispatch () at ../../dix/dispatch.c:437
#20 0x0000000000432d9d in main (argc=8, argv=0x7fffae676e58, envp=<value optimized out>)
    at ../../dix/main.c:397

This happens to me when I play a video using codeine (xine backend) for the second time. I had similar crashes with 2.6.1 intel driver thus I moved to a more recent version, but still the same problem.

Mind that I use vga=0x318 as boot parameter and hence vesa console. Feel free to request any information.

Regards,

Created attachment 24520 [details]
Xorg log

Sorry, I forgot hardware:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)

Toshiba laptop intel core 2 duo.

The "OS" for this bug got changed from NetBSD to OpenBSD, but the new followup report is for "Linux". Since it is now Linux, I now re-add Gordon to the Cc.

I'm not sure if you two are with the same bug. Jeremy, can you reproduce steadily with playing video?

I can't reproduce by playing video. I am not sure how to reproduce it. It has happened maybe 15 times over past two weeks. Just happened again this morning. Back trace of today's Xorg core dump looks the same. I have tried xf86-video-intel-2.6.99.902 and now xf86-video-intel-2.6.99.903 but they don't even detect a screen so X.org fails. At least 2.6.3 partially works. Since my backtrace shows libdrm, I am now trying with libdrm 2.4.7 and see if that helps.

Should I open a new ticket to track down why xf86-video-intel-2.6.99.903  doesn't work (no screens found)?

I am running xorg server 1.4.2 -- I am guessing that doesn't matter since xf86-video-intel configure, build and run didn't complain about old Xorg.

(In reply to comment #7)
> I can't reproduce by playing video. I am not sure how to reproduce it. It has
> happened maybe 15 times over past two weeks. Just happened again this morning.
> Back trace of today's Xorg core dump looks the same. I have tried
> xf86-video-intel-2.6.99.902 and now xf86-video-intel-2.6.99.903 but they don't
> even detect a screen so X.org fails. At least 2.6.3 partially works. Since my
> backtrace shows libdrm, I am now trying with libdrm 2.4.7 and see if that
> helps.
> 
> Should I open a new ticket to track down why xf86-video-intel-2.6.99.903 
> doesn't work (no screens found)?

yes, please. You could refer to http://intellinuxgraphics.org/how_to_report_bug.html.

Adjusting severity: crashes & hangs should be marked critical.

Raul's bug is

commit 11a853bd8e5d907fe7f5bd907453bcdac9032861
Author: Keith Packard <keithp@keithp.com>
Date:   Fri May 1 11:51:13 2009 -0700

    Hold reference to video binding table until all rects are painted.

but it's not the reporter's bug at all.

It is unhelpful to keep these bugs open on known buggy versions of the drivers simply because the infrastructure to test fixes is lacking. Hopefully the situation will improve in the near future and we will be able to start work again on an updated userspace.