I've seen that a few times... My analysis was that there's a fixed number of GEM objects and we're running out of them. Which means that the GPU is either locked up or way way WAY behind. However I haven't confirmed any part of this... just based on reading the code. In my case, the GPU was, in fact, locking up.

The original qtwebengine bug is at https://bugreports.qt.io/browse/QTBUG-41242

One interesting thing I discovered was that using the EGL/GLES mode instead of GLX/GL solved the issue. I assume at your level it shouldn't be that different. So it could be a difference in how EGL vs GLX acts.

(In reply to Allan Sandfeld from comment #2)
> The original qtwebengine bug is at
> https://bugreports.qt.io/browse/QTBUG-41242
> 
> One interesting thing I discovered was that using the EGL/GLES mode instead
> of GLX/GL solved the issue. I assume at your level it shouldn't be that
> different. So it could be a difference in how EGL vs GLX acts.

The issue was happening for me with Unigine Heaven run with DRI3 + DRI_PRIME=1. Then I started running it with vblank_mode=0 and all my problems disappeared. I haven't checked whether removing vblank_mode=0 would cause the issues to reappear. I was happy to blame it on the DRI3 boogeyman and moved on (I tend not to have a good grasp on these types of issues in the first place... normally I wouldn't touch DRI3 but it really makes nouveau dev quite a bit easier with a primary non-nvidia adapter since I can load/unload nouveau/nvidia at will and still have things display on my regular screen).

Not sure how vsync would cause the problems, but I was getting actual shader traps reported in dmesg. Do you (or whoever is having the issue) have that as well?

Hi,

any news on this issue ?

I'm running quite fresh system (OpenMandriva Lx 3.0) with:
Qt 5.6.1
Mesa 12.0-rc4
libdrm 2.4.68
kernel 4.62

gfx card nv92

and Qupzilla 2.01 crashes for me with this error 


[tpg@lazur ~]$ LC_ALL=C qupzilla
QupZilla: 0 extensions loaded
Uncaught TypeError: Cannot read property 'restoreData' of null
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch10: krec 0 pushes 0 bufs 1 relocs 0
nouveau: ch10: buf 00000000 00000002 00000004 00000004 00000000
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch10: krec 0 pushes 0 bufs 1 relocs 0
nouveau: ch10: buf 00000000 00000002 00000004 00000004 00000000
ATTENTION: default value of option force_s3tc_enable overridden by environment.
QupZilla: Starting with profile 'default'
QupZilla: 0 extensions loaded
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch11: krec 0 pushes 0 bufs 2 relocs 0
nouveau: ch11: buf 00000000 00000002 00000004 00000004 00000000
nouveau: ch11: buf 00000001 00000006 00000004 00000000 00000004
nouveau: kernel rejected pushbuf: No such file or directory
nouveau: ch11: krec 0 pushes 0 bufs 1 relocs 0
nouveau: ch11: buf 00000000 00000002 00000004 00000004 00000000
qupzilla: pushbuf.c:727: void nouveau_pushbuf_data(struct nouveau_pushbuf *, struct nouveau_bo *, uint64_t, uint64_t): Warunek zapewnienia `kref' nie został spełniony.

I can't start the Qupzilla web browser because of a crash, and the problem seems to be related to nouveau. I can run qupzilla just file if I use the --disable-gpu commandline option. Please see https://github.com/QupZilla/qupzilla/issues/2046 for the original bug I submitted. I'm going to attach the qupzilla gdb backtrace. I'm using mesa-12.0.1-5 on a Parabola GNU/Linux-libre system.

Created attachment 125441 [details]
gdb backtrace for qupzilla

Created attachment 125493 [details]
backtrace with symbol tables

- Made with gdb with the command: thread apply all bt full
- Packages versions (on a Gentoo system):
www-client/qupzilla-2.0.1
x11-drivers/xf86-video-nouveau-1.0.12
media-libs/mesa-12.0.1
x11-libs/libdrm-2.4.70
dev-qt/qtwebengine-5.6.1

Unfortunately "this" issue is a lot of potential issues. The current leading cause of such errors, assuming an up-to-date libdrm/etc, is multithreading in the application. Nouveau does not handle this well.

I have a branch which tries to address this:

https://github.com/imirkin/mesa/commits/locking

However it's not quite there yet (although it's a good part of the way there), and needs a rethink on some of the core mechanisms used. Unfortunately the libdrm_nouveau api is really not well-suited to multithreading, kicks can end up resulting implicitly from all kinds of seemingly innocuous actions.

(In reply to Ilia Mirkin from comment #8)
> Unfortunately "this" issue is a lot of potential issues. The current leading
> cause of such errors, assuming an up-to-date libdrm/etc, is multithreading
> in the application. Nouveau does not handle this well.
> 

This may not be "all the way there", but I can confirm a significantly more stable experience with qtwebengine.

As a matter of fact QtWebEngine does use multithreading. Chromium renders in one thread, and Qt composites in another.

Looks like this is a well known issue, see related bug for more info.

Same here with qupzilla. But Chromium is working fine.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1080.