search for: nvkm_event_send

...b8d>] ? _raw_spin_unlock_irqrestore+0xd/0x10 [<f7e1d170>] ? drm_handle_vblank+0x210/0x360 [drm] [<f85c8dd8>] nvkm_client_ntfy+0x78/0x80 [nouveau] [<f8536ed8>] nvkm_client_notify+0x28/0x30 [nouveau] [<f8539cb5>] nvkm_notify_send+0x75/0x120 [nouveau] [<f8537d95>] nvkm_event_send+0xb5/0xe0 [nouveau] [<f85c58fe>] nvkm_sw_chan_mthd+0x5e/0x80 [nouveau] [<f85c4f91>] nvkm_sw_mthd+0x91/0xb0 [nouveau] [<f8596d8f>] nv04_fifo_intr+0x5ff/0x770 [nouveau] [<c0ac2b8d>] ? _raw_spin_unlock_irqrestore+0xd/0x10 [<f8537d7b>] ? nvkm_event_send+0x9b/0xe0 [nou...

...eau] (drivers/gpu/drm/nouveau/nouveau_nvif.c:81) nvkm_client_notify+0xea/0x140 [nouveau] (drivers/gpu/drm/nouveau/nvkm/core/client.c:46) ? _raw_spin_unlock_irqrestore+0x4b/0x50 (kernel/locking/spinlock.c:190) nvkm_notify_send+0x224/0x520 [nouveau] (drivers/gpu/drm/nouveau/nvkm/core/notify.c:92) nvkm_event_send+0x208/0x270 [nouveau] (drivers/gpu/drm/nouveau/nvkm/core/event.c:54) nvkm_disp_vblank+0x74/0x90 [nouveau] (drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c:85) ? nvkm_disp_dtor+0x540/0x540 [nouveau] (drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c:247) gf119_disp_intr+0x1d6/0x690 [nouveau] (drive...

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

Hi there, Resending these now that they've had some more polish and testing, and I heard that Ben's vacation is over :-) These patches work as a starting point for more explicit error mechanisms and better robustness. At the moment, when a job hangs or faults, it seems that nouveau doesn't quite know how to handle the situation and often results in a hang. Some of these situations

...180 [nouveau] [ 1079.221819] [<ffffffffa0552aed>] ? nvkm_sw_mthd+0x8d/0xe0 [nouveau] [ 1079.221862] [<ffffffffa04c4c51>] ? nvkm_event_get+0x71/0x80 [nouveau] [ 1079.221906] [<ffffffffa04c6a9e>] ? nvkm_notify_send+0x3e/0x130 [nouveau] [ 1079.221950] [<ffffffffa04c4d28>] ? nvkm_event_send+0xc8/0xe0 [nouveau] [ 1079.222001] [<ffffffffa051627d>] ? nvkm_disp_vblank+0x3d/0x60 [nouveau] [ 1079.222052] [<ffffffffa0504d40>] ? nvkm_mc_intr+0x70/0x110 [nouveau] [ 1079.222100] [<ffffffffa05091d1>] ? nvkm_pci_intr+0x51/0x90 [nouveau] [ 1079.222134] [<ffffffff810c683d&g...

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

From: Thierry Reding <treding at nvidia.com> Hi Ben, here's a revised subset of the patches I had sent out a couple of weeks ago. I've reworked the BAR2 accesses in the way that you had suggested, which at least for GP10B turned out to be fairly trivial to do. I have not looked in detail at this for GV11B yet, but a cursory look showed that BAR2 is accessed in more places, so the

From: Jérôme Glisse <jglisse at redhat.com> (mm is cced just to allow exposure of device driver work without ccing a long list of peoples. I do not think there is anything usefull to discuss from mm point of view but i might be wrong, so just for the curious :)). git://people.freedesktop.org/~glisse/linux branch: nouveau-hmm-v00