similar to: [PATCH] drm: nouveau: use larger buffer in nvif_vmm_map

Displaying 20 results from an estimated 300 matches similar to: "[PATCH] drm: nouveau: use larger buffer in nvif_vmm_map"

2017 Nov 28
2
[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)
This is a false positive, but I wonder if it is really necessary to put the assignment in the conditional test expression. julia ---------- Forwarded message ---------- Date: Tue, 28 Nov 2017 13:23:36 +0800 From: kbuild test robot <fengguang.wu at intel.com> To: kbuild at 01.org Cc: Julia Lawall <julia.lawall at lip6.fr> Subject: [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci
2017 Nov 28
0
[PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)
Hi julia, I think it would be better to extract the assignment out of the if clause. Then you'll get something like this: memory = ...; if (IS_ERR(memory)) { .... } so, to answer your question: no, it isn't necessary. On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall <julia.lawall at lip6.fr> wrote: > This is a false positive, but I wonder if it is really necessary to put > the
2019 May 17
4
drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks
Hello, 5.1.0-next-20190517 I'm looking at quite a lot of kmemleak reports coming from drm/nouveau/core/memory, all of which are: unreferenced object 0xffff8deec27c4ac0 (size 16): comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:
2008 Jan 17
1
Under DTrace USDT and PID, kernel''s microstat accounting doesn''t work in this situation, doesn''t it?
Does anyone has any ideas about this problem? 2008/1/15, ?? TaoJie <eulertao at gmail.com>: > > Hi all: > > I''m working on revealing system performance now. > My testing program is an infinite loop. Inside the loop, it will do some > mathematical opertaions and call function callee(), then go to the next > loop. > I install a alarm(30) in the program. It
2018 Mar 10
17
[RFC PATCH 00/13] SVM (share virtual memory) with HMM in nouveau
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
2019 Oct 09
3
[Bug 111940] New: frequent timeout warnings during normal operation
https://bugs.freedesktop.org/show_bug.cgi?id=111940 Bug ID: 111940 Summary: frequent timeout warnings during normal operation Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Driver/nouveau
2019 May 17
0
drm/nouveau/core/memory: kmemleak 684 new suspected memory leaks
On (05/17/19 15:13), Sergey Senozhatsky wrote: > 5.1.0-next-20190517 > > I'm looking at quite a lot of kmemleak reports coming from > drm/nouveau/core/memory, all of which are: > > unreferenced object 0xffff8deec27c4ac0 (size 16): > comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) > hex dump (first 16 bytes): > 00 00
2019 Sep 10
1
[Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote: > On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding <thierry.reding at gmail.com> wrote: > > > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > > > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann <kraxel at redhat.com> wrote: > > > > > > > > Hi, > > > >
2019 Feb 23
0
[Bug 101220] [NV137/GP107] xorg-server-1.19.3 crashes when trying to enable HDMI output
https://bugs.freedesktop.org/show_bug.cgi?id=101220 --- Comment #19 from Pacho Ramos <pachoramos1 at gmail.com> --- Any news on this? I still need to run with noaccel with kernel 4.19.25, otherwise system ends up getting hung after showing this errors: feb 23 17:21:08 dell-2017 kernel: ------------[ cut here ]------------ feb 23 17:21:08 dell-2017 kernel: nouveau 0000:01:00.0: timeout feb
2019 Sep 27
5
[Bug 111843] New: Resume fails after suspend with nouveau and Gtx 1050 ti
https://bugs.freedesktop.org/show_bug.cgi?id=111843 Bug ID: 111843 Summary: Resume fails after suspend with nouveau and Gtx 1050 ti Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Driver/nouveau
2018 Sep 03
4
[Bug 107818] New: linux-4.18.5 every boot some drivers errors
https://bugs.freedesktop.org/show_bug.cgi?id=107818 Bug ID: 107818 Summary: linux-4.18.5 every boot some drivers errors Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at
2023 Feb 04
1
[PATCH] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33: warning: array subscript 'unsigned char[16][0]' is partly outside array bounds of 'u8[15]' {aka
2023 May 22
0
[PATCH 6.3 004/364] drm/nouveau/disp: More DP_RECEIVER_CAP_SIZE array fixes
From: Kees Cook <keescook at chromium.org> [ Upstream commit 25feda6fbd0cfefcb69308fb20d4d4815a107c5e ] More arrays (and arguments) for dcpd were set to 16, when it looks like DP_RECEIVER_CAP_SIZE (15) should be used. Fix the remaining cases, seen with GCC 13: ../drivers/gpu/drm/nouveau/nvif/outp.c: In function 'nvif_outp_acquire_dp': ../include/linux/fortify-string.h:57:33:
2019 Nov 08
0
[PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h
In preparation for allowing architectures to define their own implementation of the 'READ_ONCE()' macro, move the generic '{READ,WRITE}_ONCE()' definitions out of the unwieldy 'linux/compiler.h' and into a new 'rwonce.h' header under 'asm-generic'. Signed-off-by: Will Deacon <will at kernel.org> --- include/asm-generic/Kbuild | 1 +
2018 Jan 25
0
[PATCH net-next 11/12] tools/virtio: copy READ/WRITE_ONCE
This is to make ptr_ring test build again. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- tools/virtio/ringtest/main.h | 57 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/tools/virtio/ringtest/main.h b/tools/virtio/ringtest/main.h index 5706e07..593a328 100644 --- a/tools/virtio/ringtest/main.h +++ b/tools/virtio/ringtest/main.h @@
2018 Apr 03
2
nouveau TRAP_M2MF still there on G98
Hi! In commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0: > drm/nouveau/mmu: ALIGN_DOWN correct variable > > Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round > for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN, > but erroneously applied ALIGN_DOWN to a different variable (addr) and left > intended variable (tail) not
2019 Apr 26
2
[RFC][clang/llvm] Allow efficient implementation of libc's memory functions in C/C++
*TL;DR:* Defining memory functions in C / C++ results in a chicken and egg problem. Clang can mutate the code into semantically equivalent calls to libc. None of `-fno-builtin-memcpy`, `-ffreestanding` nor `-nostdlib` provide a satisfactory answer to the problem. *Goal* Create libc's memory functions (aka `memcpy`, `memset`, `memcmp`, ...) in C++ to benefit from compiler's knowledge and
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the
2016 Nov 25
5
[PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()
On 11/25/2016 05:17 PM, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 04:10:04PM +0000, Mark Rutland wrote: >> On Fri, Nov 25, 2016 at 04:21:39PM +0100, Dmitry Vyukov wrote: > >>> What are use cases for such primitive that won't be OK with "read once >>> _and_ atomically"? >> >> I have none to hand. > > Whatever triggers the
2019 Nov 11
1
[PATCH 01/13] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h
On Mon, Nov 11, 2019 at 9:10 AM Christian Borntraeger <borntraeger at de.ibm.com> wrote: > On 08.11.19 20:57, Arnd Bergmann wrote: > > On Fri, Nov 8, 2019 at 6:01 PM Will Deacon <will at kernel.org> wrote: > >> > >> In preparation for allowing architectures to define their own > >> implementation of the 'READ_ONCE()' macro, move the generic