search for: ramht

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/d...

Most calls to nvkm_ramht_new use 0x8000 as the size. This results in a fairly sizeable chunk of memory to be allocated, which may not be available with kzalloc. Since this is done fairly rarely (once per channel), use vzalloc instead. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/core/ra...

...;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 good idea, those should probably be fixed up as well. drm/nouveau/nvkm/engine/fifo/dmanv04.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drm/nouveau/nvkm/engine/fifo/dmanv04.c b/drm/nouveau/nvkm/engine/fifo/dmanv04.c index...

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

...HE_ERROR - ch 6 [glxgears[15559]] subc 0 mthd 0x0060 data 0x8000000f c1p0 0x20000010 HASH_FAILED (unknown bits 0x20000000) c1_hash 0x00000436 What I found so far: 1) It's triggered by setting of NV11_SUBCHAN_DMA_SEMAPHORE to NvSema (0x8000000f) in nv84_fence_emit. Hw tells us it cannot find ramht entry for NvSema object (NV04_PFIFO_CACHE1_PULL0 == HASH_FAILED, frequently unknown 30th bit is set) 2) In 95% cases CACHE_ERRORs are triggered on glxgears channel. 3) RAMHT entry was definitely created and used many times before reporting an error. Next use of NvSema usually does NOT trig...

...t nouveau_fifo_engine fifo; - spinlock_t lock; }; struct nouveau_pll_vals { @@ -534,6 +533,9 @@ struct drm_nouveau_private { struct nouveau_engine engine; struct nouveau_channel *channel; + /* For PFIFO and PGRAPH. */ + spinlock_t context_switch_lock; + /* RAMIN configuration, RAMFC, RAMHT and RAMRO offsets */ struct nouveau_gpuobj *ramht; uint32_t ramin_rsvd_vram; diff --git a/drivers/gpu/drm/nouveau/nouveau_irq.c b/drivers/gpu/drm/nouveau/nouveau_irq.c index cffc9bc..95220dd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_irq.c +++ b/drivers/gpu/drm/nouveau/nouveau_irq.c @@ -697,7...

...ails 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 stumbling at is that I see the PFIFO_DMA_PUSHER, which I am to understand means: "Oh, the GPU obj operation you stuck on the RAMHT/RAMIN is busted." So first of, is there a register to poke to find out which DMA operation it is talking about ? Or is it pretty fast - so I can surmise that: [ 13.271499] [drm] nouveau 0000:01:00.0: nouveau_ramht_hash_handle:75 - ch0 handle=0x80000001 [ 13.271499] [drm] nouveau 0000:01:...

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

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

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

...ffffff8114d2c4>] warn_alloc_failed+0xd4/0x120 [<ffffffff8114f853>] __alloc_pages_nodemask+0x103/0x780 [<ffffffff811500d2>] alloc_kmem_pages+0x12/0x20 [<ffffffff81161a03>] kmalloc_order+0x13/0x40 [<ffffffff8117a517>] __kmalloc+0xb7/0xf0 [<ffffffff813e87b0>] nvkm_ramht_new+0x40/0xf0 [<ffffffff8144ff40>] g84_fifo_chan_ctor+0x140/0x170 [<ffffffff81451b87>] g84_fifo_gpfifo_new+0xc7/0x300 [<ffffffff8143c366>] ? nvkm_disp_class_get+0x26/0x60 [<ffffffff81449d02>] nvkm_fifo_class_new+0x12/0x20 [<ffffffff8143baf1>] nvkm_udevice_child_ne...

...lank screen (and also uses "nouveau" driver). I think this is a regression in the "nouveau" graphic driver : the version bundled with lucid alpha 3 works, the one with lucid beta 2 (or fedora 13 beta) does not. Here is an excerpt of the dmesg on beta 2 : nouveau 0000:03:00.0: RAMHT space exhausted. ch=0 nouveau 0000:03:00.0: Error referencing VRAM ctxdma: -12 nouveau 0000:03:00.0: gpuobj -12 This error message does not appear when using lucid alpha 3. I found that adding "nouveau.noaccel=1" as a boot parameter is a workaround, both on ubuntu lucid beta 2 and o...

....h diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile index 998e8b4..3d9d484 100644 --- a/drivers/gpu/drm/nouveau/Makefile +++ b/drivers/gpu/drm/nouveau/Makefile @@ -23,6 +23,7 @@ nouveau-y += core/core/parent.o nouveau-y += core/core/printk.o nouveau-y += core/core/ramht.o nouveau-y += core/core/subdev.o +nouveau-y += core/core/xtensa.o nouveau-y += core/subdev/bar/base.o nouveau-y += core/subdev/bar/nv50.o @@ -135,6 +136,7 @@ nouveau-y += core/engine/dmaobj/nv50.o nouveau-y += core/engine/dmaobj/nvc0.o nouveau-y += core/engine/dmaobj/nvd0.o nouveau-y += co...

...e-Identifier: GPL-2.0 */ include/nvkm/core/oproxy.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/option.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/os.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/pci.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/ramht.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/subdev.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/core/tegra.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/engine/bsp.h:/* SPDX-License-Identifier: GPL-2.0 */ include/nvkm/engine/ce.h:/* SPDX-License-Identifier: GPL-2.0 *...

...all: irq=18 Aug 6 21:11:46 localhost [drm:nouveau_irq_preinstall] IRQ: preinst Aug 6 21:11:46 localhost [drm:nouveau_irq_postinstall] IRQ: postinst Aug 6 21:11:46 localhost [drm:nv04_instmem_determine_amount] RAMIN size: 1024KiB Aug 6 21:11:46 localhost [drm:nv04_instmem_configure_fixed_tables] RAMHT offset=0x10000, size=512 Aug 6 21:11:46 localhost [drm:nv04_instmem_configure_fixed_tables] RAMRO offset=0x11200, size=512 Aug 6 21:11:46 localhost [drm:nv04_instmem_configure_fixed_tables] RAMFC offset=0x20000, size=4096 Aug 6 21:11:46 localhost [drm:nouveau_mem_init] Available VRAM: 130048KiB...

...e/nvkm/core/oproxy.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/option.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/os.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/pci.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/ramht.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/core/tegra.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/engine/bsp.h | 2 +- drivers/gpu/drm/nouveau/include/nvkm/engine/ce.h...

...rol the backlight of your display (e.g. a laptop panel). + +endif diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile index d310c19..8f40be9 100644 --- a/drivers/gpu/drm/nouveau/Makefile +++ b/drivers/gpu/drm/nouveau/Makefile @@ -24,8 +24,9 @@ nouveau-y += core/core/ramht.o nouveau-y += core/core/subdev.o nouveau-y += core/subdev/bar/base.o -nouveau-y += core/subdev/bar/nv50.o -nouveau-y += core/subdev/bar/nvc0.o +nouveau-$(CONFIG_DRM_NOUVEAU_NV50) += core/subdev/bar/nv50.o +nouveau-$(CONFIG_DRM_NOUVEAU_NVC0) += core/subdev/bar/nv50.o +nouveau-$(CONFIG_DRM_NOUVE...

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

Hi everyone, Apologies for the big patchset. This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send

This is a rework of the secure boot code that moves the building of the blob into its own set of source files (and own hooks), making the code more flexible and (hopefully) easier to understand as well. This rework is needed to support more signed firmware for existing and new chips. Since the firmwares in question are not available yet I cannot send the code to manage then, but hopefully the