Created attachment 128876 [details]
glmark2 apitrace

This is an apitrace of glmark2 hitting th bkref assertion. I've used apitrace at commit 849af14927410b5cd8a9597a39bd7f636ae54644.

Does running the apitrace in question cause the assert to happen?

(In reply to Ilia Mirkin from comment #2)
> Does running the apitrace in question cause the assert to happen?

Yes it does:

apitrace replay apitrace.out

[...]

glretrace: pushbuf.c:238: pushbuf_krel: Assertion `bkref' failed.
apitrace: warning: caught signal 6
16922: error: caught an unhandled exception
glretrace+0x2b391d
glretrace+0x2b3116
glretrace+0x2b132c
linux-gate.so.1+0xb3b
/lib/libc.so.6: gsignal+0xbd
/lib/libc.so.6: abort+0x16c
/lib/libc.so.6+0x27eb4
/lib/libc.so.6: __assert_fail+0x57
/usr/lib/libdrm_nouveau.so.2: pushbuf_krel+0x3ce3: /tmp/libdrm-2.4.74/nouveau/pushbuf.c:238
/usr/lib/libdrm_nouveau.so.2: nouveau_pushbuf_reloc+0x44: /tmp/libdrm-2.4.74/nouveau/pushbuf.c:746
/usr/lib/xorg/modules/dri/nouveau_dri.so: PUSH_RELOC+0x541f38: ./nv30/nv30_winsys.h:26
/usr/lib/xorg/modules/dri/nouveau_dri.so: nv30_transfer_copy_data+0x544701: nv30/nv30_transfer.c:740
/usr/lib/xorg/modules/dri/nouveau_dri.so: nouveau_transfer_write+0x528d0c: /tmp/mesa-13.0.3/src/gallium/drivers/nouveau/nouveau_buffer.c:211
/usr/lib/xorg/modules/dri/nouveau_dri.so: nouveau_buffer_transfer_unmap+0x52976e: /tmp/mesa-13.0.3/src/gallium/drivers/nouveau/nouveau_buffer.c:544
/usr/lib/xorg/modules/dri/nouveau_dri.so: u_transfer_unmap_vtbl+0x4526ad: util/u_transfer.c:154
/usr/lib/xorg/modules/dri/nouveau_dri.so: pipe_transfer_unmap+0x452321: ./util/u_inlines.h:457
/usr/lib/xorg/modules/dri/nouveau_dri.so: u_default_buffer_subdata+0x4523eb: util/u_transfer.c:35
/usr/lib/xorg/modules/dri/nouveau_dri.so: pipe_buffer_write+0x235686: ../../src/gallium/auxiliary/util/u_inlines.h:345
/usr/lib/xorg/modules/dri/nouveau_dri.so: st_bufferobj_subdata+0x235836: state_tracker/st_cb_bufferobjects.c:132
/usr/lib/xorg/modules/dri/nouveau_dri.so: _mesa_buffer_sub_data+0x5ff8d: main/bufferobj.c:1804
/usr/lib/xorg/modules/dri/nouveau_dri.so: _mesa_BufferSubData+0x60015: main/bufferobj.c:1818
glretrace+0x142273
glretrace+0x93096
glretrace+0x84afc
glretrace+0x86cfc
glretrace+0x86c6f
glretrace+0x84e46
glretrace+0x85013
glretrace+0x85a7f
/lib/libc.so.6: __libc_start_main+0x106
glretrace+0x81ba0: ../sysdeps/i386/start.S:115
apitrace: info: taking default action for signal 6

Cool thanks! I think a similar issue has been reported before, and I stared at that code with little success. Having a reproducible issue that I can poke at should definitely make success (in at least understanding, if not fixing) much more likely.

While I was not able to hit the issue by replaying your trace, I grabbed glmark2, and with

MESA_GL_VERSION_OVERRIDE=2.0 ./build/src/glmark2 -b buffer:columns=200:interleave=false:update-dispersion=0.99:update-fraction=0.5:update-method=subdata:buffer-usage=static

(built with the x11-gl target) it indeed fails on my NV34. Will start digging.

I have been unable to trigger the issue locally with the following mesa patch:

https://patchwork.freedesktop.org/patch/132414/

Please try to see if this also resolves your problems.

I've applied your patch on top of mesa 13.0.3 (there was a conflict in
nvc0_query_hw.c, but it doesn't matter with my hardware).

I've been running
gdb --args ./glmark2 -b buffer:columns=200:interleave=false:update-dispersion=0.99:update-fraction=0.5:update-method=subdata:buffer-usage=static --run-forever
for 30 minutes now, so I guess this issue is fixed.

Thank you, Ilia.

Changing status to resolved-fixed.