|Summary:||Assert in nouveau_pushbuf_data|
|Product:||Mesa||Reporter:||Allan Sandfeld Jensen <kde>|
|Component:||Drivers/DRI/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Nouveau Project <nouveau>|
|Priority:||medium||CC:||andrey.aleksandrovich, anssi, fdsfgs, freedesktop-bugs, freedesktop.org, fturco, heirecka, jefferym, pfeiffer, rdieter, ridai.govinda, ryan|
|i915 platform:||i915 features:|
gdb backtrace for qupzilla
backtrace with symbol tables
Description Allan Sandfeld Jensen 2015-08-14 08:26:09 UTC
I have been looking into why QtWebEngine crashes with the nouveau driver, but the crashes appears asserts in the driver and not our code. Any idea about what could trigger it: #3 0x00007ffff0f032d2 in __GI___assert_fail (assertion=assertion@entry=0x7fffe1d77aa9 "kref", file=file@entry=0x7fffe1d77a8a "../../nouveau/pushbuf.c", line=line@entry=726, function=function@entry=0x7fffe1d77ad0 <__PRETTY_FUNCTION__.6213> "nouveau_pushbuf_data") at assert.c:101 #4 0x00007fffe1d76284 in nouveau_pushbuf_data (push=push@entry=0x598d40, bo=0x5ace30, offset=115624, length=20) at ../../nouveau/pushbuf.c:726 #5 0x00007fffe1d761cb in nouveau_pushbuf_data (push=push@entry=0x598d40, bo=bo@entry=0x0, offset=offset@entry=0, length=length@entry=0) at ../../nouveau/pushbuf.c:718 #6 0x00007fffe1d762ea in pushbuf_submit (push=push@entry=0x598d40, chan=<optimized out>, chan=<optimized out>) at ../../nouveau/pushbuf.c:329 #7 0x00007fffe1d7656e in pushbuf_flush (push=push@entry=0x598d40) at ../../nouveau/pushbuf.c:404 #8 0x00007fffe1d77180 in nouveau_pushbuf_kick (push=0x598d40, chan=<optimized out>) at ../../nouveau/pushbuf.c:778 #9 0x00007fffe246d766 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so #10 0x00007fffe2182024 in ?? () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so <snip> #15 0x00007ffff1cda345 in glXMakeCurrentReadSGI () from /usr/lib/x86_64-linux-gnu/libGL.so.1
Comment 1 Ilia Mirkin 2015-08-24 13:24:40 UTC
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.
Comment 2 Allan Sandfeld Jensen 2015-08-24 13:46:42 UTC
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.
Comment 3 Ilia Mirkin 2015-08-24 13:55:18 UTC
(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?
Comment 4 Tomasz Paweł Gajc 2016-06-28 16:03:30 UTC
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.
Comment 5 Francesco Turco 2016-07-30 19:07:59 UTC
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.
Comment 6 Francesco Turco 2016-07-30 19:08:32 UTC
Created attachment 125441 [details] gdb backtrace for qupzilla
Comment 7 Andrés Becerra Sandoval 2016-08-02 20:17:56 UTC
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
Comment 8 Ilia Mirkin 2016-08-02 23:09:54 UTC
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.
Comment 9 Reuben 2016-08-03 04:15:45 UTC
(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.
Comment 10 Allan Sandfeld Jensen 2016-08-03 08:25:36 UTC
As a matter of fact QtWebEngine does use multithreading. Chromium renders in one thread, and Qt composites in another.
Comment 11 Tomasz Paweł Gajc 2016-12-10 14:44:58 UTC
Looks like this is a well known issue, see related bug for more info.
Comment 12 Andrey 2017-05-01 12:21:55 UTC
Same here with qupzilla. But Chromium is working fine.
Comment 13 GitLab Migration User 2019-09-18 20:40:29 UTC
-- 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.