[Nouveau] Struggle with GPU lockups and console deadlock using kernel-space modifications

[Innocenti Maresin]

There were some genuine GPU lockups (with older drivers), but
in the previous mail I misidentified my current problem,
that turned out to be a deadlocked Xorg.
It possibly is caused by hardware malfunction, as there is a plenty of
Oct  6 21:46:35 duk kernel: [  686.096701] nouveau 0000:01:00.0: fb:
trapped read at 0020014110 on channel 1 [0fcae000 DRM] engine 0c
[SEMAPHORE_BG] client 08 [PFIFO_READ] subclient 00 [] reason 0000000f
[DMAOBJ_LIMIT]
Oct  6 21:46:36 duk kernel: [  686.273035] nouveau 0000:01:00.0: fb:
trapped read at 0020012040 on channel 1 [0fcae000 DRM] engine 0c
[SEMAPHORE_BG] client 08 [PFIFO_READ] subclient 00 [] reason 0000000f
[DMAOBJ_LIMIT]
Oct  6 21:46:36 duk kernel: [  686.303822] nouveau 0000:01:00.0: fifo:
CACHE_ERROR - ch 1 [DRM] subc 7 mthd 1ffc data 00ffffff
Oct  6 21:46:36 duk kernel: [  686.303843] nouveau 0000:01:00.0: fifo:
CACHE_ERROR - ch 1 [DRM] subc 7 mthd 1ffc data 00ffffff
in kern.log,
but GPU actually runs software and I even can move a mouse pointer sometimes.

When switching VC from the Xorg’s console is requested
(no matter with which keys or API), the kernel sends Xorg the SIGUSR1 signal.
When Xorg is locked up, it won’t allow to proceed with switching consoles.

>  • «⧦->devinit->post = true; nvkm_device_init(⧦);» without reset —
>    to be tested.
Not very interesting.
Video signal dies out (just as with config=NvForcePost=1),
but nouveau technically continues to work,
and locked up Xorg wastes CPU time.
Also, programmed reboot becomes impossible (system crashes on attempt to do it).

Regards, Incnis Mrsi