similar to: [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()

Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Alexandre, could you

Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM,

This reverts commit 1addc1264852 This commit seems to cause crashes in gk104_fifo_intr_runlist() by returning 0xbad0da00 when register 0x2a00 is read. Since this commit was intended for GM20B which is not completely supported yet, let's revert it for the time being. Reported-by: Eric Biggers <ebiggers3 at gmail.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> ---

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

On Mon, Mar 07, 2016 at 11:10:16AM +0900, Alexandre Courbot wrote: > > Hi Eric, just to follow up - are you still happy with this patch? Yes, I still haven't had any problems with it.

The offset should be 8 on Kepler and later. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gk104.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Hi, According to the header[1] the offset for engine status register is 8. [1] https://github.com/kfractal/nouveau/blob/hwref/drm/nouveau/include/nvkm/hwref/gk104/fifo.h Thanks, Vince diff --git

On Wed, Aug 12, 2015 at 3:00 PM, Afzal Mohammed <afzal.mohd.ma at gmail.com> wrote: > Hi, > > On Wed, Aug 12, 2015 at 01:17:38PM +0900, Alexandre Courbot wrote: >> This reverts commit 1addc1264852 >> >> This commit seems to cause crashes in gk104_fifo_intr_runlist() by >> returning 0xbad0da00 when register 0x2a00 is read. Since this commit was >>

On Wed, Mar 2, 2016 at 12:53 PM, Eric Biggers <ebiggers3 at gmail.com> wrote: > On Tue, Mar 01, 2016 at 04:59:05PM +0900, Alexandre Courbot wrote: >> >> Eric, since you reported the regression on the first version, would you mind trying >> this one and giving us your Tested-by? I have tested it on dGPU but unfortunately >> could not set it up in an optimus-like

Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system memory. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/fifo/gf100.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/engine/fifo/gf100.c

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

Signed-off-by: ZhiHu <huzhi001 at 208suo.com> --- .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c index d8a4d773a58c..b99e0a7c96bb 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c +++

not sure how i got signed up for this and i don?t see a way to unsubscribe. this is flooding my email with things i don?t care about. On Fri, Jul 14, 2023, at 1:14 AM, huzhi001 at 208suo.com wrote: > Signed-off-by: ZhiHu <huzhi001 at 208suo.com> > --- > .../gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 40 ++++++++++++++----- > 1 file changed, 29 insertions(+), 11 deletions(-)

NAK - checkpatch.pl is a (strongish) guideline, but not a rule. In the cases corrected in the patch series here, we format the switch cases on single lines as it dramatically improves the readability of what is otherwise just a /long/ list of slightly different static mappings. I don't believe we're the only part of the kernel to do this either. On Fri, 2023-07-14 at 14:58 +0800, huzhi001

A channel may still be processed by the PBDMA even after removal, unless it is properly kicked. Some chips are more sensible to this than others, with GM20B triggering the issue very easily (the PBDMA will try to fetch methods from the previously-removed channel after a new one is added). Make sure this cannot happen by kicking the channel right after it is disabled, and before the new runlist is

These chipsets include the VP2 engine which is composed of a bitstream processor (BSP) that decodes H.264 and a video processor (VP) which can do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are driven by separate xtensa chips embedded in the hardware. This patch provides the mechanism to load the kernel for the xtensa chips and provide the necessary interactions to do the rest of

smatch reports drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:33:18: warning: symbol 'nvkm_engn_cgrp_get' was not declared. Should it be static? nvkm_engn_cgrp_get is only used in runl.c, so it should be static Signed-off-by: Tom Rix <trix at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

https://bugs.freedesktop.org/show_bug.cgi?id=99584 Bug ID: 99584 Summary: XVMC on nv43 class card broken with recent mesa + kernel. Product: Mesa Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

Changes since last sent: * add a patch to set the device into DRM_SWITCH_POWER_CHANGING state (can be dropped actually, I thought I was needing it, came up with a different approach and forgot to delete it, doesn't hurt though) * expose information about runtime suspending to nvkm so that we can run the pcie workaround only on runtime suspend Karol Herbst (8): pci: disable ASPM

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous