Bug 82152

Created attachment 104018 [details]
Output from crashing glxinfo.

Created attachment 104019 [details]
Kernel logs filtered from journal output.

Created attachment 104020 [details]
Xorg.0.log from crash.

There are two issues:

(a) The null deref in the kernel when putting the card back to sleep
(b) The fact that init of the card fails

To mitigate the first, you could boot with "nouveau.runpm=0". However you still wouldn't get working accel with nouveau.

The claim by NVIDIA was that the graph-not-powered-up problem was restricted to GK104/GK106. But looking at the latest code, it seems like it runs on GK107 as well (not in Ben's repo anymore, but still in linux-3.16) and perhaps has the reverse effect there.

I wonder if a patch like

diff --git a/nvkm/engine/graph/nve4.c b/nvkm/engine/graph/nve4.c
index 51e0c07..4dd376e 100644
--- a/nvkm/engine/graph/nve4.c
+++ b/nvkm/engine/graph/nve4.c
@@ -350,7 +350,7 @@ nve4_graph_oclass = &(struct nvc0_graph_oclass) {
                .ctor = nvc0_graph_ctor,
                .dtor = nvc0_graph_dtor,
                .init = nve4_graph_init,
-               .fini = nve4_graph_fini,
+               .fini = _nouveau_graph_fini,
        },
        .cclass = &nve4_grctx_oclass,
        .sclass = nve4_graph_sclass,

will help you out. (You'll need to apply it with care... cd into drivers/gpu/drm/nouveau/core and apply it with patch -p2 )

I get the same crash and HUB_INIT timeout after the patch. Attaching dmesg.

Created attachment 104026 [details]
dmesg output post initial patch.

If i look at the system + the kernel bug, this looks similar to a problem i was facing some weeks ago:

so i'd suggest to try DRI3 with the whole package:

Update your packages:
xf86-video-intel
mesa
(all dependencies of course)
Remove:
xf86-video-nouveau (with DRI3 you wont need it to do: DRI_PRIME=1 myprog)


you'll need a kernel with rendernodes enabled (boot with drm.rnodes=1)
you may need to add a file to /etc/udev/rules.d/ containing:

SUBSYSTEM=="drm", IMPORT{builtin}="path_id" 

to get ID_PATH tags for rendernodes.

Created attachment 104031 [details]
dmesg output using DRI3

Using DRI3 defers all errors until after attempting to run an OpenGL application with DRI_PRIME=1, and prevents the crash from bringing down X or the kernel.

Created attachment 104033 [details]
dmesg output using firmware ripped from the blob

Using DRI3 and the firmware from the blob I still get crashes, but finally have a different error message in dmesg.

Tried again with Linux 3.19.3 and Mesa 10.5.2, no changes.

Created attachment 122992 [details]
dmesg output with errors from successful load

With Linux 4.5.0-ARCH, Mesa 11.1.2-3, DRI3, and using modesetting_drv instead of intel_drv for the main display (not sure if that's relevant)... everything works! (If "everything" consists of glxinfo, glxgears, and a few minutes of Darwinia.)

I do still get errors in dmesg, though, as attached. I'll be happy to follow along and do whatever digging is necessary to eradicate them, if someone wants to take up that task.

-- 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/1066.