Bug 102349

Created attachment 133709 [details] [review]
hackpatch

OK, so it looks like a PUSH_RESET happens when there's no bufctx is bound. I can definitely see how that can happen, unfortunately -- if a context becomes active and is then deleted, then the screen's pushbuf->user_priv = NULL. Then a PUSH_RESET comes in, and *boom*. This is a giant hack, but I suspect this patch could resolve the issue.

Thanks for the patch. Mesa is been rebuild with this patch. Still crashing:

Thread 7 (Thread 0x7fff4189b700 (LWP 1745)):
#0  0x00007ffff271f6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffede4b9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffede4bb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff303404f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff2fdd9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff2e0b0f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff5de6406 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x00007ffff2e0fda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 6 (Thread 0x7fffd0f55700 (LWP 1744)):
#0  0x00007ffff1ce915f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007ffff786b2c4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#2  0x00007ffff786b309 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Script.so.5
#3  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#4  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 5 (Thread 0x7fffd2bb6700 (LWP 1742)):
#0  0x00007ffff271f6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffede4b9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffede4bb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff303404f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff2fdd9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff2e0b0f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff545d6a5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007ffff2e0fda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 4 (Thread 0x7fffe0ed1700 (LWP 1741)):
#0  0x00007ffff271f6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffede4b9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffede4bb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff303404f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff2fdd9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff2e0b0f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff545d6a5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007ffff2e0fda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7fffe1f0d700 (LWP 1733)):
#0  0x00007ffff271f6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fffede4b9f6 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007fffede4bb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff303404f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff2fdd9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff2e0b0f3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff7f4b6d5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007ffff2e0fda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7fffe2b7a700 (LWP 1727)):
#0  0x00007ffff271f6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff67b3150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ffff67b4ee9 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fffe4490b69 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007ffff2e0fda8 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff1ce3494 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x00007ffff2728aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7ffff7e0a940 (LWP 1723)):
#0  0x00007fff4b70c22d in PUSH_RESET (bin=0, push=0x555555bef630) at ../../../../../src/gallium/drivers/nouveau/nv30/nv30_winsys.h:39
#1  nv30_validate_fb (nv30=0x555555fb42f0) at ../../../../../src/gallium/drivers/nouveau/nv30/nv30_state_validate.c:102
#2  0x00007fff4b70cb29 in nv30_state_validate (nv30=nv30@entry=0x555555fb42f0, mask=mask@entry=10240, hwtnl=hwtnl@entry=true) at ../../../../../src/gallium/drivers/nouveau/nv30/nv30_state_validate.c:493
#3  0x00007fff4b700f05 in nv30_clear (pipe=0x555555fb42f0, buffers=5, color=0x555555f834c4, depth=1, stencil=0) at ../../../../../src/gallium/drivers/nouveau/nv30/nv30_clear.c:61
#4  0x00007fff4b458771 in st_Clear (ctx=0x555555f81a10, mask=272) at ../../../src/mesa/state_tracker/st_cb_clear.c:481
#5  0x00007ffff5e1594a in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x00007ffff5e1b215 in QSGBatchRenderer::Renderer::render() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x00007ffff5e26b3f in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#8  0x00007ffff5e5daa6 in QSGDefaultLayer::grab() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x00007ffff5e5df55 in QSGDefaultLayer::updateTexture() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x00007ffff5f6b556 in QQuickShaderEffectMaterial::updateTextures() const () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007ffff5e273b7 in QSGRenderer::preprocess() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#12 0x00007ffff5e26b0f in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x00007ffff5e2720b in QSGRenderer::renderScene(unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#14 0x00007ffff5e36eae in QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x00007ffff5e8076e in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#16 0x00007ffff5e4d9a5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#17 0x00007ffff5e8b216 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#18 0x00007ffff38c2b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x00007ffff38ca341 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x00007ffff2fdf9e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#21 0x00007ffff333360e in QWindowPrivate::deliverUpdateRequest() () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#22 0x00007ffff3333b59 in QWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#23 0x00007ffff5e8b1b5 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#24 0x00007ffff38c2b8c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x00007ffff38ca341 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#26 0x00007ffff2fdf9e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x00007ffff3032fee in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x00007ffff3033511 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#29 0x00007fffede4b7f7 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x00007fffede4ba60 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x00007fffede4bb0c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#32 0x00007ffff303404f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007ffff2fdd9ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007ffff2fe613c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#35 0x0000555555572daf in main (argc=<optimized out>, argv=<optimized out>) at ./shell/main.cpp:166

F*&#$%. Of course. In the nv30_clear path. Can you throw

   push->user_priv = &nv30->bufctx;

Somewhere towards the top of nv30_clear (before it calls nv30_state_validate)

Created attachment 133733 [details] [review]
hackpatch2

For your convenience, a replacement test patch.

Actually I have to admit... while I had a plausible explanation for the first instance, I do not for the second. Context deletion correctly cleans this stuff up, nv30_state_validate should check if a new context is being used and set up the new pointers.

The way nv30 handles bufctx stuff is different than nv50+, and I don't think it's with good reason. I may try rewriting it.

The
" push->user_priv = &nv30->bufctx;

Somewhere towards the top of nv30_clear (before it calls nv30_state_validate)"

patch worked. I got into the desktop screen.
In the desktop screen i have now again the known errors with colored rectangles beginning in one of the corners and stretching over the whole screen. Should i open for those a new bugreport? How can those be properly reported?

imirkin, i had send you additional on private (because of data privacy) a trace of the problem. You told that you have got it.

What are the plans on fixing this bug?

Error also exist on Geforce 7900 - NV49 (G71)

Hello? Any help in near future? When would i be able to use the computer as expected?

Ping (and I wonder if this couldn't be any related to Steam segfaults)

Can someone please help with this error? Its there for such a long time. Please help.

Created attachment 142336 [details]
backtrace of plasmashell process

Same problem here using Fedora 29 rpms. Backtrace attached.

Device: NV44 GeForce 6600 LE 512MB DDR2

System: Fedora 29 x86_64
Mesa DRI drivers: 18.2.2-1.fc29
Nouveau: 1.0.15-6.fc29
Plasmashell: 5.13.5-1.fc29

(In reply to mirh from comment #10)
> Ping (and I wonder if this couldn't be any related to Steam segfaults)

It appears that it is. At least I just tried to run steam on top of a NV34 and this is the cause of a crash there after logging in. The password screen is pretty broken already due to steam trying to use NPOT textures, but those should work OK on nv4x.

Still no clue why it's happening, but at least I can repro myself now, which means I can investigate properly.

I believe the issue is mostly resolved by:

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

There's a lingering issue, which I don't think was truly being hit, but fixed by:

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

Of course when I went to test these patches with xonotic, I was immediately confronted by the fact that we don't handle 3d transfers (which ~never used to happen before, but some recent improvements have made it a thing that happens a lot more often). I quickly hacked around that with the below patch, but that's obviously not generally acceptable.

diff --git a/src/gallium/auxiliary/util/u_transfer.c b/src/gallium/auxiliary/util/u_transfer.c
index 3089bcb1f34..3550e1e26d3 100644
--- a/src/gallium/auxiliary/util/u_transfer.c
+++ b/src/gallium/auxiliary/util/u_transfer.c
@@ -56,11 +56,16 @@ void u_default_texture_subdata(struct pipe_context *pipe,
    /* texture_subdata implicitly discards the rewritten buffer range */
    usage |= PIPE_TRANSFER_DISCARD_RANGE;
 
+   for (int z = box->z; z < box->z + box->depth; z++) {
+      struct pipe_box t = *box;
+      t.z = z;
+      t.depth = 1;
+
    map = pipe->transfer_map(pipe,
                             resource,
                             level,
                             usage,
-                            box, &transfer);
+                            &t, &transfer);
    if (!map)
       return;
 
@@ -71,13 +76,14 @@ void u_default_texture_subdata(struct pipe_context *pipe,
                  0, 0, 0,
                  box->width,
                  box->height,
-                 box->depth,
+                 1,
                  src_data,
                  stride,       /* bytes */
                  layer_stride, /* bytes */
-                 0, 0, 0);
+                 0, 0, t.z);
 
    pipe_transfer_unmap(pipe, transfer);
+   }
 }

FWIW xonotic looks terrible on the nv34 -- all the colors are messed up, and maybe some of the geometry too. But it's the same with 18.3.

OK, this and some other bits are now pushed to mesa master. I'm considering this resolved.

People having issues with steam -- try out steam. I tested that it the client loads OK for me but didn't go any further. Friendly reminder that it's a 32-bit application, not 64-bit.

People having issues with plasmashell -- try out plasmashell. Although I expect you'll keep having issues, they'll just be different ones.

Not fixed in Mesa 18.2.8 for Fedora 29. Plasmashell keeps segfaulting.
Screen turns black with only the cursor. Konsole and other programs 
runs fine, except for plasmashell and sddm-greeter.


[  168.028608] plasmashell[2006]: segfault at 0 ip 00007f82250821d9 sp 00007ffc81db2e70 error 4 in nouveau_dri.so[7f8224b6e000+820000]

[   35.532730] nouveau 0000:03:00.0: sddm-greeter[1013]: fail ttm_validate
[   35.532737] nouveau 0000:03:00.0: sddm-greeter[1013]: validating bo list
[   35.532766] nouveau 0000:03:00.0: sddm-greeter[1013]: validate: -12

(In reply to Christian Tosta from comment #16)
> Not fixed in Mesa 18.2.8 for Fedora 29. Plasmashell keeps segfaulting.
> Screen turns black with only the cursor. Konsole and other programs 
> runs fine, except for plasmashell and sddm-greeter.

Nor is it expected to be fixed in that version. I pushed the changes to master, you'll have to build that (or get something for your distro which follows the latest development).

Ok, sorry. I understood that it was available in 18.2.8 (released last 27/12 and packaged 28/12 for Fedora) not for master branch. I'll wait for that to be released. Workaround it disabling acceleration for Nouveau adding "nouveau.noaccel=1" to cmdline.

-- 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/xorg/driver/xf86-video-nouveau/issues/364.