similar to: [PATCH 1/3] drm/nv50: include vp in the fb error reporting mask

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

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> --- 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 +++

ARB_sampler_object is very simple software only extension to support. I want to make it mandator extension for Mesa drivers to allow meta module to use it. This patch add support for the extension to nouveau. It is completely untested search and replace patch. I hope someone with old NV hardware could give a try that there is no regressions and ARB_sampler_object tests passes. Signed-off-by:

When hash collision occurs and it's near ramht object boundary, we could read and possibly overwrite some memory after ramht object. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: stable at vger.kernel.org --- drivers/gpu/drm/nouveau/core/core/ramht.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/core/ramht.c

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

- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>

Hi all, I'm hoping someone more knowledgeable in Fortran than I can chime in with opinion. I'm the maintainer of the flashClust package that implements fast hierarchical clustering. The fortran code fails when the number of clustered objects is larger than about 46300. My guess is that this is because the code uses the following construct: IOFFSET=J+(I-1)*N-(I*(I+1))/2 where N is the

--- rnndb/memory/nvc0_pbfb.xml | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) diff --git a/rnndb/memory/nvc0_pbfb.xml b/rnndb/memory/nvc0_pbfb.xml index 500cea9..e006dbe 100644 --- a/rnndb/memory/nvc0_pbfb.xml +++ b/rnndb/memory/nvc0_pbfb.xml @@ -49,23 +49,54 @@ Most bitfields are unknown. </doc> <bitfield high="7"

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: stable at vger.kernel.org --- Ian Romanick reported a kernel crash that implicated this path in a null pointer jump, which means that one of the function pointers had been nulled out. Not sure if a race there would explain it, but maybe. There is also questionable ramht usage in channv50 and various disp code. If you think this is a

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> --- drivers/gpu/drm/nouveau/core/engine/graph/nv40.h | 3 +++ drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 10 ++-------- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h b/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h index 7da35a4..ad82093 100644 ---

https://bugs.freedesktop.org/show_bug.cgi?id=92892 Bug ID: 92892 Summary: KDE Plasma locks up: Nouveau reports error "resource sanity check" "unable to handle kernel paging request" Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

https://bugs.freedesktop.org/show_bug.cgi?id=58087 Priority: medium Bug ID: 58087 Assignee: nouveau at lists.freedesktop.org Summary: [-next] nouveau corrupts kernel mm allocator QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter at

Hello, I am kernel engineer working on PV-OPS kernel trying to get it work in Dom0 with an NVidia (NV30 right now) card. But there are issues, such as that the pv-ops kernel has a different understanding of memory (for details check out: http://wiki.xensource.com/xenwiki/XenPVOPSDRM). I've fleshed out most of them (like GART had the wrong phys addresses, ouch!), but the one that I am

Hi, I try to use lm to fit a linear model with 600k rows and 70 attributes. But I can't even load the data into the R environment. The error message says the vector memory is used up. Is there anyone having experience with large datasets in R? (I bet) Please advise. thanks, Yun-Fang [[alternative HTML version deleted]]

* Kill the A8+A8 hack. Recent enough X servers (>=1.7) fall back to ARGB glyphs for drivers not supporting A8 render targets. * Kill all the global state. It doesn't matter a lot yet but it might if we get multicard working at some point. * Other random clean-ups with no functional changes. Some numbers from x11perf -aa10text -aa24text -comppixwin10 -comppixwin500: * Before, with A

This has two purposes : - cleaner code - reduce the diff between nv30 and nv40 exa for a possible nvfx_exa merge ? The main differences seem to be that nv30 uses rect texture format (and does not support repeat on that). Then there are some minor changes in TX_FORMAT RT_FORMAT and TEX_FILTER usage. And NVAccelInitNVx0TCL look complete different. Tested with: ./rendercheck -t

http://bugs.freedesktop.org/show_bug.cgi?id=17357 Summary: NV4B 10DE:0393 funny stripes in video flash when using nouveau Product: xorg Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau