similar to: [PATCH] drm/nouveau: fix lockdep splat in display

>From recent additional locking in nouveau, it looks like we see recursive lock acquisition in 3.8-rc6: nouveau [ DEVICE][0000:01:00.0] BOOT0 : 0x0e7150a2 nouveau [ DEVICE][0000:01:00.0] Chipset: GK107 (NVE7) nouveau [ DEVICE][0000:01:00.0] Family : NVE0 nouveau [ VBIOS][0000:01:00.0] checking PRAMIN for image... nouveau [ VBIOS][0000:01:00.0] ... appears to be valid nouveau [

Testing airlied's current drm-fixes branch gives me this, with lockdep enabled: [ 40.864179] ============================================= [ 40.864179] [ INFO: possible recursive locking detected ] [ 40.864179] 3.8.0-rc3-patser+ #915 Tainted: G W [ 40.864179] --------------------------------------------- [ 40.864179] modprobe/524 is trying to acquire lock: [ 40.864179]

Full piglit run with this patch: http://people.freedesktop.org/~mslusarz/chan_owners.txt This patch covers only a small subset of all error messages, so: Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Comments? Ideas? (This commit depends on this one: http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch ) ---

Allow the software channel to be created now, since methods for vblanking have been implemented. The instmem flush seems to be needed on fermi to prevent a race, but I enabled it on earlier cards too since they seem to be susceptible to the same race. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 9 ----

From: Lauri Peltonen <lpeltonen at nvidia.com> Notify interrupt is only used for cyclestats. We can just clear it and avoid an "unknown stat" error that gets printed to dmesg otherwise. Signed-off-by: Lauri Peltonen <lpeltonen at nvidia.com> Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drm/nouveau/nvkm/engine/gr/gf100.c | 9 +++++++++ 1 file changed,

The inst variable (and thus engctx) will not be properly populated for pre-NV44 cards. The dma setter method didn't need it anyways, so call it directly instead of the nv_call indirection. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on NV42. Ben, I'm going to guess that you hate this patch, since it gets rid of the beautiful nv_call stuff. However I wasn't

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > 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

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

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is

Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- This patch relies on "drm/nouveau: remove >1 sclass support from nouveau_parent_create_". There are *many* *more* code paths without proper error handling - I counted at least 106 in 41 functions. If someone would like to do a bit of janitorial work I marked those code paths and uploaded "patch" here:

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

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx lookup") Cc: stable at vger.kernel.org # v4.3+ --- This is just a nice-to-have, as it only affects an error print afterwards. drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 2 +- drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c | 2 +- 2 files changed,

In this case, no class is available but the bind methods is sent too, so use it to keep track of what channel is 'bound' and find the software class id from it. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- calim can I get a tested-by? drivers/gpu/drm/nouveau/nouveau_software.h | 1 + drivers/gpu/drm/nouveau/nvc0_software.c | 35

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c b/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c index c190043..5c54aa1 100644 --- a/drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c +++

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_connector.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h index 6e399aa..4cefce3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.h +++ b/drivers/gpu/drm/nouveau/nouveau_connector.h @@ -107,7 +107,4

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not 100% sure that this is needed, but BSP/MPEG are in the mask. drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c b/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c index 0cb322a..f25fc5f 100644 ---

https://bugzilla.netfilter.org/show_bug.cgi?id=1092 Bug ID: 1092 Summary: nft v0.6 segfault in must_print_eq_op at expression.c:520 during 'nft monitor trace' in netdev filter Product: nftables Version: unspecified Hardware: x86_64 OS: All Status: NEW

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I made the assumption that showing the address is generally useful. Worst case, it won't make sense but still be displayed. Seems simpler than special-casing things. drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 117 ++++++++++++----------- 1 file changed, 63 insertions(+), 54 deletions(-) diff --git

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

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git