Innocenti Maresin
2015-Oct-06 20:06 UTC
[Nouveau] Struggle with GPU lockups and console deadlock using kernel-space modifications
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