I need 'addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0xbf149 0xbfecc'

addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0xbf149 0xbfecc
xf86-video-intel-2.21.3/src/sna/kgem.h:347
xf86-video-intel-2.21.3/src/sna/sna_dri.c:1858

addr2line -i -f -e /usr/lib64/xorg/modules/drivers/intel_drv.so 0xbf149 0xbfecc
kgem_bo_reference
xf86-video-intel-2.21.3/src/sna/kgem.h:347
sna_dri_copy_to_front
xf86-video-intel-2.21.3/src/sna/sna_dri.c:729
sna_dri_immediate_blit
xf86-video-intel-2.21.3/src/sna/sna_dri.c:1858
sna_dri_schedule_swap
xf86-video-intel-2.21.3/src/sna/sna_dri.c:2187

Hmm, that's quite scary. How frequently does this occur?

Can you also attach Xorg.0.log so that I have the full hardware info?

Created attachment 75802 [details]
Xorg.log

I can reproduce with 100% reliability with kernel 3.8.1. It never happened with kernel 3.7.9.

As you can trigger this bug trivially, do you mind recompiling xf86-video-intel with --enable-debug=full and attaching the full Xorg.log? I can see how it can explode, but I can't exactly see how it gets into that situation.

Created attachment 75807 [details]
Xorg.log with debug

Ok, that explains the missing piece of the puzzle. But opens up another question, are you manipulating capabilities on that system? The root cause of the error is that when we try to perform the vsync'ed update, we get rejected with EPERM despite being ostensibly the DRM_MASTER and CAP_SYS_ADMIN.

I have patched Xserver to drop root privileges after start-up.

You are dropping privileges after we query whether we can use a particular root-only interface. I can fix the crash, but not the bigger problem without at least a glimpse at your patch.

setgid and setuid are called before Dispatch() is called in dix/main.c

I have disabled vsync globally
vblank_mode=0
only MPlayer is started with
unset vblank_mode
If I start MPlayer without 
unset vblank_mode
there is no crash.

So after all the setup is done, and there is no appropriate callback to [re-]evaluate state after dropping privileges. I guess either do the drop earlier though that is always going to be fragile, or introduce a framework to do so and notify the drivers.

Can I patch kernel 3.8 to act as kernel 3.7
or driver to act with kernel 3.8 same as with kernel 3.7 ?
Can be added compile or runtime time option to kernel or driver  to revert acting?
Can that root-only interface be modified to work for certain non-root user?
There are devices like /dev/dri/card0, which allows only some users to talk with kernel. Can be something like that used for that  vsync'ed update?

(In reply to comment #14)
> Can I patch kernel 3.8 to act as kernel 3.7
> or driver to act with kernel 3.8 same as with kernel 3.7 ?

Option "SwapbuffersWait" "false"

> Can be added compile or runtime time option to kernel or driver  to revert
> acting?

It does a runtime check that you are subverting.

> Can that root-only interface be modified to work for certain non-root user?

No, in order to do vsync'ed updates one needs to write to hardware registers. It was such a fragile single purpose interface that we created a general purpose interface so that we could do such ugly hardware fixups from userspace within the command buffers.

> There are devices like /dev/dri/card0, which allows only some users to talk
> with kernel. Can be something like that used for that  vsync'ed update?

It is using GEM to do the updates. You've just broken the code and so get to fix it.

This should fix the crash:

commit cd313a8d5d1363929bebac83f81e347b4a9e70f1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Mar 2 22:52:15 2013 +0000

    sna/dri: Guard against failed batch submission
    
    Avoid dereferencing a NULL bo if we do not submit a batch for the copy
    operation.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61708
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

But we still lack a way of dropping privileges without confusing the driver.

Option "SwapbuffersWait" "false"
disables vsync, isn't it?

It looks like driver or kernel 3.8 are broken if vsync works with kernel 3.7+sna and kernel 3.8+uxa without root and crash.

How can be that runtime check modified to revert to 3.7 acting on kernel 3.8?

I compiled driver from git. Running MPlayer with "unset vblank_mode" few seconds causes huge performance regression.
glxgears runs at 
5100 fps before MPlayer as usually
370 fps after MPlayer - haven't seen such low fps before

(In reply to comment #17)
> It looks like driver or kernel 3.8 are broken if vsync works with kernel
> 3.7+sna and kernel 3.8+uxa without root and crash.

vsync does not work on 3.7. It requires a feature introduced in 3.8.

And UXA does not do vsync.

there is tearing when I run MPlayer with vblank_mode=0, but with "unset vblank_mode" there is no tearing on kernel 3.7

I can categorically state that is pure coincidence.

Accoring to intel manual page, it is feature of SwapbuffersWait.

If enabled, the calls will avoid tearing by making sure the display scanline is outside of the area to be copied before the copy occurs.

I can solve crash by disabling using of secure batches in driver.
Can you add xorg.conf option for disabling secure batches?

MPlayer is using glXSwapBuffers which solves tearing with any kernel.

(In reply to comment #23)
> I can solve crash by disabling using of secure batches in driver.
> Can you add xorg.conf option for disabling secure batches?

(In reply to comment #22)
> Accoring to intel manual page, it is feature of SwapbuffersWait.

I think you answered your own question.

But the root cause of this issue are your broken patches.

I didn't answered my question. 
If secure batches are enabled driver will crash if SwapbuffersWait is enabled.
If secure batches are disabled, I can have SwapbuffersWait enabled and there is neither crash nor tearing.
Can you add xorg.conf option named "SecureBatches" which will be enabled by default?